Windows-Unterstützung

Devin unterstützt Windows als Plattform für Builds und Sitzungen. Standardmäßig verwenden Windows-Umgebungen dieselbe Bash-Shell (Git Bash) wie Linux, sodass die meisten Blueprint-Befehle auf beiden Plattformen ohne Änderungen funktionieren. Blueprints können ihre Windows-Setup-Schritte aber auch in PowerShell ausführen.

Die Windows-Unterstützung ist derzeit nur eingeschränkt verfügbar. Wenn Sie Windows mit Devin ausprobieren möchten, kontaktieren Sie uns, um mehr zu erfahren und Zugriff zu erhalten.

Wie es funktioniert

Die Windows-Unterstützung basiert auf demselben System für deklarative Konfiguration wie Linux. Der wichtigste Unterschied ist das Feld runs-on in Ihrem Blueprint, das Devin mitteilt, auf welcher Plattform gebaut und ausgeführt werden soll. Über das optionale Feld shell können Sie festlegen, dass ein Windows-Block seine run-Schritte in Windows PowerShell statt in Git Bash ausführt. Da beide Plattformen standardmäßig bash verwenden, können Sie unter Linux und Windows dieselben Shell-Befehle schreiben. Die Hauptunterschiede liegen in der Dateisystemstruktur und den verfügbaren Paketmanagern:

Aspekt	Linux (Standard)	Windows
Home-Verzeichnis	`/home/ubuntu`	`/c/Users/Administrator`
Repo-Verzeichnis	`~/repos/<repo-name>`	`/c/Users/Administrator/repos/<repo-name>`
Paketmanager	`apt-get`	`choco` oder direkte Installer

Windows-Blueprints erstellen

Blueprint für eine einzelne Plattform

Wenn Ihr Repository nur für Windows ausgelegt ist, verwenden Sie auf oberster Ebene runs-on: windows:

runs-on: windows

initialize:
  - name: "Install Node.js"
    uses: github.com/actions/setup-node@v4
    with:
      node-version: "20"

  - name: "Install build tools"
    run: |
      choco install visualstudio2022buildtools -y
      choco install python --version=3.12 -y

maintenance: |
  npm install

knowledge:
  - name: lint
    contents: npm run lint
  - name: test
    contents: npm test
  - name: build
    contents: npm run build

Plattformübergreifendes Blueprint

Um dasselbe Repository sowohl für Linux als auch für Windows zu bauen, schreiben Sie jede Plattform als separates YAML-Dokument und trennen Sie die Dokumente mit ---. Jedes Dokument definiert sein eigenes runs-on-Label. Hintergrundinformationen zu diesem Format finden Sie im Hinweis Multi-document YAML im Blueprint-Leitfaden.

runs-on: default
initialize: |
  curl -LsSf https://astral.sh/uv/install.sh | sh
  apt-get update && apt-get install -y build-essential

maintenance: |
  uv sync

knowledge:
  - name: test
    contents: uv run pytest

---
runs-on: windows
initialize: |
  choco install python --version=3.12 -y

maintenance: |
  uv sync

knowledge:
  - name: test
    contents: uv run pytest

Jedes Dokument erzeugt für seine Plattform einen separaten Snapshot-Build. Sitzungen starten mit dem plattformspezifischen Snapshot.

Das YAML auf der obersten Ebene muss ein Mapping sein, keine Sequenz. Wenn Sie das obige Beispiel als einzelne Liste schreiben (- runs-on: default / - runs-on: windows), wird es vom Backend mit Invalid YAML: each YAML document must be a mapping, not a sequence; use '---' to separate multiple blocks abgelehnt. Verwenden Sie das oben gezeigte Trennzeichen ---.

Das Feld `runs-on`

Das Feld runs-on verweist auf eine registrierte Maschinenkonfiguration in Ihrem Konto:

Wert	Plattform
`default` oder `linux`	Linux (Standardplattform)
`macos`	macOS
`windows`	Windows

Sie können runs-on als Zeichenfolge oder als Liste angeben:

# Einzelne Plattform
runs-on: windows

# Mehrere Plattformen in einem Block (dieselben Befehle werden auf jeder ausgeführt)
runs-on: [default, windows]

Wenn ein Block mehrere Plattformen auflistet, erstellt das Build-System mit denselben Befehlen einen Snapshot pro Plattform.

Die Listensyntax führt auf jeder Plattform in der Liste dieselben Befehle aus. Verwenden Sie sie nur, wenn die Befehle tatsächlich plattformübergreifend sind (z. B. npm install, uv sync). Für plattformspezifische Befehle (wie apt-get unter Linux oder choco unter Windows) verwenden Sie stattdessen das Multi-Dokument-Format — ein Dokument pro Plattform, getrennt durch ---.

Das Feld `shell`

Standardmäßig werden die run-Schritte eines Blocks unter Windows in Git Bash ausgeführt. Wenn Sie Setup-Schritte stattdessen mit nativen PowerShell-Cmdlets, PowerShell-Syntax und Windows-Pfaden schreiben möchten, setzen Sie das optionale Feld shell auf oberster Ebene auf powershell:

runs-on: windows
shell: powershell

initialize:
  - name: "Install build tools"
    run: |
      choco install visualstudio2022buildtools -y
      New-Item -ItemType Directory -Force -Path "$env:USERPROFILE\tools" | Out-Null

maintenance:
  - name: "Restore packages"
    run: |
      Write-Host "Restoring packages"
      dotnet restore

Die Einstellung gilt jeweils pro Block. Setzen Sie in einem plattformübergreifenden Blueprint shell: powershell nur im Dokument mit runs-on: windows, damit das Linux-Dokument weiterhin Bash verwendet. Die Einstellung betrifft nur Build-Schritte; Windows-Sitzungen nutzen weiterhin Git Bash als Standard-Shell. Die zulässigen Werte, die Übergabe von Secrets und Umgebungsvariablen an PowerShell-Schritte sowie die Fehlerbehandlung sind unter shell in der Blueprint-Referenz beschrieben.

Nutzung und Kosten

Windows-Sitzungen verursachen im Vergleich zu entsprechenden Linux-Sitzungen etwa 9 % mehr Verbrauch (ACUs oder Kontingent). Details dazu, wie der Verbrauch erfasst wird, finden Sie unter Nutzung.

Windows-Sitzungsverhalten

Shell

In Windows-Sitzungen wird Git Bash als Standard-Shell verwendet — dieselbe Bash-Shell wie unter Linux. Sofern ein Block nicht shell: powershell festlegt, werden auch die run-Schritte eines Blueprints in Git Bash ausgeführt, sodass die Standard-Bash-Syntax auf beiden Plattformen funktioniert:

- run: |
    export MY_VAR="hello"
    echo $MY_VAR

Pfade

Git Bash verwendet Pfade im POSIX-Stil (/c/... statt C:\...):

# Linux-Pfade
- run: cp config.json ~/.config/myapp/config.json

# Windows-Pfade (Git Bash-Format)
- run: cp config.json /c/Users/Administrator/.config/myapp/config.json

Steps in einem shell: powershell-Block verwenden dagegen native Windows-Pfade:

- run: Copy-Item config.json "$env:USERPROFILE\.config\myapp\config.json"

Secrets

Secrets sind in Sitzungen als Umgebungsvariablen mit der üblichen Bash-Syntax ($SECRET_NAME) verfügbar:

maintenance:
  - name: "Configure registry"
    run: |
      npm config set //registry.npmjs.org/:_authToken $NPM_TOKEN

Dateianhänge

Unter Windows werden hochgeladene Dateien in /c/Users/Administrator/.files/ statt in /home/ubuntu/.files/ geschrieben.

Computer Use

Computer Use wird in Windows-Sitzungen vollständig unterstützt. Devin verfügt dabei über eine Windows-Desktopumgebung mit Zugriff auf Chrome, Maus und Tastatur, sodass es Web-Apps ebenso wie native Windows-Desktopanwendungen (z. B. WPF- und WinForms-Apps) testen und seine Testsitzungen aufzeichnen kann.

Blueprint-Tipps für Windows

Tools installieren

Verwenden Sie choco (Chocolatey) oder Skripte für den Direktdownload:

initialize:
  - name: "Install Chocolatey packages"
    run: |
      choco install git -y
      choco install nodejs-lts -y
      choco install python --version=3.12 -y
      choco install dotnet-sdk -y

Gängige Muster

.NET-Projekt:

runs-on: windows

initialize:
  - name: "Install .NET SDK"
    run: |
      choco install dotnet-sdk -y

maintenance: |
  dotnet restore

knowledge:
  - name: build
    contents: dotnet build
  - name: test
    contents: dotnet test
  - name: lint
    contents: dotnet format --verify-no-changes

Visual Studio / C++-Projekt:

runs-on: windows

initialize:
  - name: "Install Visual Studio Build Tools"
    run: |
      choco install visualstudio2022buildtools -y
      choco install visualstudio2022-workload-vctools -y

maintenance: |
  msbuild /t:Restore MySolution.sln

knowledge:
  - name: build
    contents: msbuild MySolution.sln /p:Configuration=Release
  - name: test
    contents: vstest.console.exe bin/Release/Tests.dll

Loslegen

Grundlegende Richtlinien

Einführung in Devin

Arbeiten mit Devin

Produktleitfäden

Integrationen

Admin

Versionshinweise

Windows-Unterstützung

Wie es funktioniert

Windows-Blueprints erstellen

Blueprint für eine einzelne Plattform

Plattformübergreifendes Blueprint

Das Feld `runs-on`

Das Feld `shell`

Nutzung und Kosten

Windows-Sitzungsverhalten

Shell

Pfade

Secrets

Dateianhänge

Computer Use

Blueprint-Tipps für Windows

Tools installieren

Gängige Muster

​Wie es funktioniert

​Windows-Blueprints erstellen

​Blueprint für eine einzelne Plattform

​Plattformübergreifendes Blueprint

​Das Feld runs-on

​Das Feld shell

​Nutzung und Kosten

​Windows-Sitzungsverhalten

​Shell

​Pfade

​Secrets

​Dateianhänge

​Computer Use

​Blueprint-Tipps für Windows

​Tools installieren

​Gängige Muster

Wie es funktioniert

Windows-Blueprints erstellen

Blueprint für eine einzelne Plattform

Plattformübergreifendes Blueprint

Das Feld `runs-on`

Das Feld `shell`

Nutzung und Kosten

Windows-Sitzungsverhalten

Shell

Pfade

Secrets

Dateianhänge

Computer Use

Blueprint-Tipps für Windows

Tools installieren

Gängige Muster