Deklarative Konfiguration

Erste Schritte

Voraussetzungen: Devin muss Zugriff auf Ihre Repositories haben, bevor Sie die Umgebung konfigurieren können. Wenn Sie Ihre Git-Integration noch nicht eingerichtet haben, finden Sie unter Bevor Sie beginnen die Einrichtungsschritte. Enterprise-Nutzer müssen außerdem jeder Org in Enterprise Settings > Repository Permissions Zugriff auf ihre Repos gewähren.

Nutzen Sie noch die klassische Konfiguration? Sie können jederzeit zur deklarativen Konfiguration migrieren. Devin kann den Großteil der Migration für Sie übernehmen. Siehe Migration zur deklarativen Konfiguration.

Devin erledigt das (empfohlen)
Manuelle Einrichtung

Am besten für die meisten Nutzer geeignet. Devin analysiert Ihr Projekt, ermittelt die benötigten Tools und Abhängigkeiten und erstellt den Blueprint für Sie. Sie müssen ihn nur prüfen und freigeben.

Eine Devin-Sitzung starten

Öffnen Sie eine neue Sitzung und bitten Sie Devin, das Repository zu konfigurieren. Zum Beispiel: “Richte deine Umgebung für dieses Repo ein.”

Prüfen und freigeben

Devin schlägt einen Blueprint vor. In Ihrer Timeline sehen Sie suggestion cards. Prüfen Sie sie und klicken Sie auf Approve.

Überprüfen

Sobald der Build abgeschlossen ist, starten Sie eine neue Sitzung. Devin startet aus dem neuen Snapshot mit bereits vollständig vorkonfigurierter Umgebung. Bitten Sie Devin, Ihre Lint- oder Testbefehle auszuführen, um zu bestätigen, dass alles funktioniert.

Am besten geeignet, wenn Sie genau wissen, was Ihre Umgebung benötigt, oder wenn Sie jeden Schritt vollständig kontrollieren möchten. Schneller, wenn Sie Ihre Befehle bereits vorbereitet haben.

Zur Umgebungskonfiguration wechseln

Gehen Sie in der Seitenleiste Ihrer Organization zu Settings > Environment > Blueprints.Wenn Sie diese Option nicht sehen, verwendet Ihre Organization möglicherweise noch die klassische Einrichtung. Unter Migration zur deklarativen Konfiguration erfahren Sie, wie Sie loslegen.

Repositories hinzufügen

Klicken Sie im Abschnitt Repositories auf Add. Wählen Sie die Repositories aus, mit denen Devin arbeiten soll, und bestätigen Sie dann.Hier hinzugefügte Repositories werden bei jedem Build in Devins Umgebung geklont. Sie können jederzeit weitere hinzufügen.

Ihren Blueprint schreiben

Klicken Sie auf ein Repository, um den Blueprint-Editor zu öffnen. Hier ist ein einfaches Beispiel:

initialize: |
  curl -LsSf https://astral.sh/uv/install.sh | sh

maintenance: |
  uv sync

knowledge:
  - name: lint
    contents: uv run ruff check .
  - name: test
    contents: uv run pytest

Weitere Sprachen und Muster finden Sie in der Vorlagenbibliothek.

Speichern und Build starten

Klicken Sie auf Save. Ein Build startet automatisch (in der Regel 2–10 Minuten). Verfolgen Sie den Fortschritt unter Settings > Environment > Snapshots bei Current build.

Überprüfen

Sobald der Build Success anzeigt, starten Sie eine neue Devin-Sitzung. Devin startet aus dem neuen Snapshot mit bereits vollständig vorkonfigurierter Umgebung. Bitten Sie Devin, Ihre Lint- oder Testbefehle auszuführen, um zu prüfen, ob die Umgebung funktioniert.

Der Rest dieses Leitfadens beschreibt den manuellen Weg im Detail. Er ist auch hilfreich, um nachzuvollziehen, was Devin erzeugt hat, wenn Sie den empfohlenen Weg verwendet haben.

Wie es funktioniert

Die deklarative Konfiguration basiert auf drei Konzepten:

Konzept	Beschreibung	Analogie
Blueprint	Eine YAML-Konfiguration, die beschreibt, was installiert werden soll und wie Devins Umgebung eingerichtet wird	Dockerfile
Build	Der Prozess, der Ihr Blueprint ausführt, Repos klont und einen Snapshot erstellt	`docker build`
Snapshot	Ein eingefrorenes, bootfähiges Abbild der Umgebung, von dem Sitzungen gestartet werden	Docker-Image

Blueprints beschreiben, was Sie möchten. Sie erstellen und bearbeiten sie in der Settings-UI. Builds führen Ihre Blueprints aus und erzeugen daraus Snapshots. Builds werden automatisch ausgeführt, wenn Sie ein Blueprint speichern, und in regelmäßigen Abständen (~alle 24 Stunden), damit Abhängigkeiten aktuell bleiben. Snapshots sind die Grundlage, von der Sitzungen starten. Jede Organisation hat genau einen aktiven Snapshot. Jede Sitzung startet mit einer frischen Kopie. Änderungen aus Sitzungen werden nicht in den Snapshot zurückgeschrieben.

Blueprint-Abschnitte

Ein Blueprint hat drei Abschnitte sowie einen optionalen clone-Block für Blueprints auf Repo-Ebene:

Abschnitt	Zweck	Wann er ausgeführt wird
`initialize`	Tools, Laufzeitumgebungen und Systempakete installieren	Nur während Builds. Ergebnisse werden im Snapshot gespeichert.
`maintenance`	Projektabhängigkeiten installieren/aktualisieren, Konfigurationen für Zugangsdaten schreiben	Während Builds. Zu Sitzungsbeginn dem Agent angezeigt (nicht automatisch ausgeführt).
`knowledge`	Referenzinformationen für Devin (Lint-, Test- und Build-Befehle)	Wird nicht ausgeführt. Zu Sitzungsbeginn in Devins Kontext geladen.
`clone`	Standardvorgaben für das Klonen des Repositorys überschreiben (nur auf Repo-Ebene)	Wird während des Clone-Schritts des Builds angewendet.

initialize ist für Dinge gedacht, die nur einmal passieren müssen: Laufzeitumgebungen, Systempakete und globale CLI-Tools. maintenance ist für die Installation von Abhängigkeiten gedacht, die aktuell bleiben sollen. Es wird während Builds ausgeführt und dem Agent zu Sitzungsbeginn angezeigt, sodass er die Befehle erneut ausführen kann, wenn sich Abhängigkeiten geändert haben (z. B. nach dem Abrufen des neuesten Codes). Befehle werden zu Sitzungsbeginn nicht automatisch ausgeführt, sollten aber dennoch schnell und inkrementell sein (verwende npm install, nicht npm ci). knowledge enthält Referenzinformationen und wird nicht ausgeführt. So teilst du Devin die richtigen Befehle für Linting, Tests und Builds mit. Halte die Einträge knapp und auf ausführbare Befehle fokussiert. clone (nur auf Repo-Ebene) überschreibt Standardvorgaben, die Devin beim Klonen des Repo in den Snapshot verwendet — zum Beispiel das Auschecken eines nicht standardmäßigen Branches (ref), das Ändern des Clone-Ziels (path) oder das Überspringen von Submodulen oder LFS-Objekten. Jedes Feld ist optional. Die vollständige Feldliste findest du unter Blueprint-Referenz → clone.

Knowledge hier vs. die Produktfunktion Knowledge: Der Abschnitt knowledge in deinem Blueprint ist für kurze Befehlsreferenzen gedacht, die an die Umgebung gebunden sind. Für Architekturdokumente, Konventionen und Team- Workflows verwende stattdessen die eigenständige Funktion Knowledge.

YAML mit mehreren Dokumenten: Der Blueprint-Editor unterstützt YAML mit mehreren Dokumenten mit dem Trennzeichen ---. So kannst du komplexe Blueprints innerhalb eines einzelnen Editors in logische Abschnitte gliedern.

Die vollständige Feldspezifikation (Schritttypen, Umgebungsvariablen, Secrets und Dateianhänge) findest du in der Blueprint-Referenz.

Geltungsbereich von Blueprints

Sie können Blueprints auf zwei Ebenen definieren:

Ebene	Wo Sie dies konfigurieren	Was Sie hier eintragen
Organisation	Settings > Environment > Blueprints > Org-wide setup	Tools, die in allen Repos gemeinsam genutzt werden: Laufzeitumgebungen, Paketmanager, Docker-Authentifizierung
Repository	Settings > Environment > Blueprints > [Repo-Name]	Projektspezifisches Setup: `npm install`, Lint-/Test-/Build-Befehle

Blueprints sind additiv: Repo-Blueprints bauen auf dem Org-Blueprint auf. Das maintenance eines Repos kann Tools verwenden, die im initialize der Organisation installiert wurden. Wenn nur ein Repo ein Tool benötigt, fügen Sie es dem Blueprint dieses Repos hinzu. Wenn es in jedem Repo benötigt wird, fügen Sie es dem Org-Blueprint hinzu.

Enterprise-Nutzer: Es gibt eine dritte Ebene, den Enterprise-Blueprint, der für alle Organisationen gilt. Weitere Informationen finden Sie unter Überblick über Enterprise-Umgebungen.

Builds und Sitzungen

Der Snapshot

Ihre Organisation hat einen aktiven Snapshot: ein VM-Image, in dem Ihre Tools, Repos und Abhängigkeiten vorinstalliert sind. Alle konfigurierten Repos werden in diesem einen Image geklont und eingerichtet. Jede Sitzung startet mit einer frischen Kopie.

So funktionieren Builds

Ein Build erstellt einen neuen Snapshot, indem Ihre Blueprints nacheinander ausgeführt werden:

1. Enterprise-Blueprint, if configured (runs in ~):
   a. initialize
   b. maintenance
2. Org-Blueprint (runs in ~):
   a. initialize
   b. maintenance
3. Alle Repositorys klonen (bis zu 10 gleichzeitig).
   Das Blueprint eines Repos kann die Clone-Standardwerte über den
   `clone`-Block überschreiben (Branch/Tag, Tiefe, Submodule, LFS usw.).
4. For each configured repo, in the order shown in Settings
   (runs in ~/repos/<repo-name>):
   a. initialize
   b. maintenance
5. Health check, then snapshot is saved

Schichten sind additiv: repo-spezifische Befehle können Tools verwenden, die von der Org oder dem Enterprise-Blueprint installiert wurden. Untergeordnete Ebenen können nicht außer Kraft setzen, was auf einer höheren Ebene eingerichtet wurde. Builds dauern in der Regel 5–15 Minuten. Für einzelne Schritte gilt ein Timeout von 1 Stunde.

Wie Sitzungen funktionieren

Jede Sitzung startet mit einer frischen Kopie des Snapshots. Wenn die Sitzung endet, werden alle Änderungen verworfen. Beim Sitzungsstart:

Der neueste Code wird für die relevanten Repos abgerufen.
maintenance-Befehle (Enterprise-, organisations- und repo-weit) werden dem Agenten als Kontext bereitgestellt — nicht automatisch ausgeführt. Der Agent kann sie erneut ausführen, wenn er erkennt, dass sich Abhängigkeiten seit dem letzten Build geändert haben.
Die Knowledge-Einträge dieses Repos werden in Devins Kontext geladen.

Knowledge ist repo-spezifisch. Wenn Sie 5 Repos konfiguriert haben, sieht Devin nur die Knowledge-Einträge des Repos, an dem gerade gearbeitet wird.

Was einen Build auslöst

Trigger	Beschreibung
Speichern eines Blueprints	Erstellen, Aktualisieren oder Löschen eines Blueprints
Hinzufügen oder Entfernen eines Repositorys	Jede Änderung an der Repository-Liste
Hinzufügen eines Repository-Secrets	Neue Secrets erfordern einen Rebuild, bevor sie verfügbar sind
Manuelles Auslösen	Klicken auf Build snapshot in der UI
Periodische Aktualisierung	Automatisch, etwa alle 24 Stunden
Devin-Vorschlag	Devin schlägt während einer Sitzung eine Änderung am Blueprint vor

Es kann jeweils nur ein Build gleichzeitig ausgeführt werden. Neue Auslöser brechen jeden Build in der Warteschlange ab und starten ihn neu.

Build-Status

Status	Bedeutung
Success	Alle Schritte wurden abgeschlossen. Der Snapshot ist bereit.
Partial	Einige Schritte auf Repo-Ebene sind fehlgeschlagen, aber der Snapshot ist nutzbar. Erfolgreiche Repos funktionieren normal; fehlgeschlagene Repos erfordern Korrekturen an ihren Blueprints.
Failed	Kritischer Fehler (die Einrichtung der org oder von Enterprise ist fehlgeschlagen). Der Snapshot ist nicht nutzbar.
Cancelled	Wurde durch einen neueren Build ersetzt oder manuell abgebrochen.

Ein teilweiser Build erzeugt trotzdem einen funktionierenden Snapshot. Wenn eines von fünf Repos einen fehlerhaften Blueprint hat, sind die anderen vier vollständig funktionsfähig.

Build schlägt fehl? Unter Fehlerbehebung bei Builds finden Sie eine Schritt-für-Schritt-Anleitung zum Debuggen.

Ihre Umgebung verwalten

Repository-Zustände

Repositories erscheinen in den Environment-Einstellungen in drei Zuständen:

Status	Bedeutung
Konfiguriert	Verfügt über eine Blueprint mit Initialize-/Maintenance-/Knowledge-Anweisungen. Im Snapshot vollständig eingerichtet.
Enthalten	In den Snapshot geklont, hat aber keine benutzerdefinierte Blueprint. Devin kann auf den Code zugreifen.
Verfügbar	Mit der Organisation verbunden, aber nicht zur Umgebung hinzugefügt. Nicht geklont.

Enthalten vs. konfiguriert: Ein „enthaltenes“ Repo wird in den Snapshot geklont, damit Devin auf den Code zugreifen kann, hat aber keine benutzerdefinierten Setup-Befehle. Ein „konfiguriertes“ Repo hat explizite Initialize-/Maintenance-/Knowledge-Anweisungen.

Secrets

Verweisen Sie mit der Syntax $VARIABLE_NAME auf Secrets. Legen Sie sie im Tab Secrets im Blueprint-Editor an.

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

Secrets stehen während Builds und Sitzungen als Umgebungsvariablen zur Verfügung. Sie werden entfernt, bevor der Snapshot gespeichert wird. Wenn jedoch ein Befehl während initialize einen geheimen Wert in eine Konfigurationsdatei schreibt, bleibt dieser Wert im Snapshot erhalten. Platzieren Sie Schritte zum Schreiben von Anmeldedaten in maintenance, damit sie bei regelmäßigen Builds aktualisiert werden. Weitere Informationen zu den Geltungsbereichen und zum Verhalten von Secrets finden Sie in der Blueprint-Referenz.

Mehrere Repositories

Jedes Repo erhält eine eigene Blueprint. Während eines Builds werden alle Repos im selben Snapshot eingerichtet, in separate Verzeichnisse geklont, und die Abhängigkeiten werden jeweils unabhängig voneinander installiert. Wenn zwei Repos unterschiedliche Versionen eines globalen Tools installieren oder gemeinsam genutzte Dateien (wie ~/.bashrc) ändern, gilt die zuletzt ausgeführte Änderung. Platzieren Sie gemeinsame Tool-Installationen in der organisationsweiten Blueprint, um Konflikte zu vermeiden.

GitHub Actions

Anstatt Shell-Skripte zum Installieren von Tools und Laufzeitumgebungen zu schreiben, können Sie GitHub Actions direkt in Ihrem Blueprint referenzieren. Devin lädt die Action während des Builds herunter und führt sie aus – genauso wie GitHubs CI-Runner Action-Schritte ausführen.

initialize:
  - name: Install Python 3.12
    uses: github.com/actions/setup-python@v5
    with:
      python-version: "3.12"

Das ist besonders nützlich bei Setup-Actions für Programmiersprachen wie setup-python, setup-node und setup-go, die Versionsverwaltung und PATH-Konfiguration automatisch übernehmen. Details zur Syntax, Beispiele und Einschränkungen finden Sie unter GitHub Actions in Blueprints.

Monorepos

Sie können Befehle mithilfe von Subshells in Unterverzeichnissen ausführen oder dedizierte, auf den jeweiligen Workspace zugeschnittene Blueprints für einzelne Pakete erstellen. Devin unterstützt auch Knowledge-Einträge pro Paket, sodass jeder Workspace eigene Lint-, Test- und Build-Befehle hat. Siehe Workspaces und Monorepos für Setup-Anleitungen und Beispiele.

Anpinnen und automatische Updates

Standardmäßig verwendet Devin den Snapshot des zuletzt erfolgreichen Builds. Mit dem Anpinnen können Sie den Snapshot eines bestimmten Builds festlegen. Das ist nützlich, wenn ein neuer Build eine Regression verursacht oder wenn Sie die Umgebung für eine Reihe von Sitzungen einfrieren möchten. So pinnen Sie an: Gehen Sie zu Settings > Environment > Snapshots, suchen Sie den Build im Verlauf (muss success oder partial sein und darf nicht älter als 7 Tage sein) und klicken Sie auf Pin. Solange ein Snapshot angepinnt ist, werden regelmäßige Aktualisierungen übersprungen und in der Benutzeroberfläche wird Automatische Updates pausiert angezeigt. So heben Sie das Anpinnen auf: Klicken Sie auf Automatische Updates fortsetzen. Devin wechselt zum zuletzt erfolgreichen Build.

Git-basierte Blueprints

Sie können Blueprints als .devin/blueprint.yaml-Dateien direkt in Ihrem Repository speichern. Nachdem Sie Änderungen zusammengeführt haben, rufen Sie die Sync-API auf (oder klicken Sie in der UI auf Sync), um das Blueprint zu aktualisieren, und starten Sie dann einen Build. So nutzen Sie denselben Code-Review-Workflow wie für Ihren Anwendungscode, wobei die Synchronisierung über einen CI-Schritt automatisiert wird. Unter Git-backed blueprints finden Sie Anleitungen zur Einrichtung und weitere Details.

Build-Probleme beheben

Schritt „Initialize“ fehlgeschlagen

Häufige Ursachen: Tippfehler in einem Shell-Befehl, Paket nicht verfügbar, Netzwerk-Timeout, falsche GitHub-Action-Referenz. Behebung: Prüfen Sie die Build-Logs auf die genaue Fehlermeldung. Aktualisieren Sie initialize in Ihrem Blueprint und speichern Sie. Ein neuer Build wird automatisch ausgelöst.

Repository konnte nicht geklont werden

Häufige Ursachen: Devin hat keinen Zugriff auf das Repository, das Repository wurde umbenannt/verschoben/gelöscht, oder es liegt ein vorübergehendes Netzwerkproblem vor. Lösung: Überprüfen Sie den Zugriff auf das Repository in den Settings Ihres Git-Anbieters. Entfernen Sie das Repository und fügen Sie es erneut hinzu, wenn es umbenannt wurde.

Maintenance-Schritt fehlgeschlagen

Häufige Ursachen: Abhängigkeitskonflikt, fehlende Systembibliothek, zu wenig Speicherplatz, Lock-Datei nicht auf dem neuesten Stand. Behebung: Prüfen Sie die Logs des fehlgeschlagenen Pakets bzw. Befehls. Aktualisieren Sie Maintenance oder initialize, damit fehlende Abhängigkeiten installiert werden, oder korrigieren Sie die Lock-Datei in Ihrem Repository.

Build-Timeout

Für jeden Schritt gilt ein Timeout von 1 Stunde. Häufige Ursachen: das Kompilieren großer nativer Abhängigkeiten aus dem Quellcode (verwenden Sie vorkompilierte Binärdateien), das Herunterladen großer Artefakte sowie Befehle, die auf Eingaben warten und dadurch hängen bleiben (alle Befehle müssen nicht interaktiv sein).

Fixes iterativ verbessern

Prüfen Sie die Build-Logs, um den Fehler zu identifizieren
Aktualisieren Sie den relevanten Blueprint
Speichern Sie (ein neuer Build wird automatisch ausgelöst)
Überwachen Sie die Logs des neuen Builds
Wiederholen Sie den Vorgang, bis der Build erfolgreich ist

Sie müssen nicht warten, bis ein fehlgeschlagener Build beendet ist. Wenn Sie eine neue Konfiguration speichern, wird jeder in der Warteschlange befindliche Build abgebrochen und ein neuer gestartet.

Nächste Schritte

Differentielle Builds

Beschleunigen Sie Builds, indem Sie nur die Workspaces neu erstellen, deren Blueprints geändert wurden.

GitHub Actions in Blueprints

Verwenden Sie GitHub Actions, um Sprachen, Tools und SDKs zu installieren, ohne Shell-Skripte schreiben zu müssen.

Workspaces und Monorepos

Subshells, Workspace-Geltungsbereiche und Knowledge-Einträge für Repositories mit mehreren Paketen.

Blueprint-Referenz

Vollständige Feldreferenz: Schritttypen, Umgebungsvariablen, Secrets und Dateianhänge.

Vorlagenbibliothek

Blueprints zum Kopieren und Einfügen für Python, Node.js, Go, Java, Ruby, Rust und erweiterte Muster.

Git-basierte Blueprints

Speichern Sie Blueprints in Ihrem Repo als .devin/blueprint.yaml und synchronisieren Sie sie über API oder UI.

Migration von der klassischen Einrichtung

Schritt-für-Schritt-Anleitung für den Wechsel vom interaktiven Assistenten zu deklarativen Blueprints.

Enterprise-Umgebungsverwaltung

Unternehmensweite Umgebungsverwaltung: 3-stufige Hierarchie, Secrets und organisationsübergreifende Konfiguration.

​Erste Schritte

​Wie es funktioniert

​Blueprint-Abschnitte

​Geltungsbereich von Blueprints

​Builds und Sitzungen

​Der Snapshot

​So funktionieren Builds

​Wie Sitzungen funktionieren

​Was einen Build auslöst

​Build-Status

​Ihre Umgebung verwalten

​Repository-Zustände

​Secrets

​Mehrere Repositories

​GitHub Actions

​Monorepos

​Anpinnen und automatische Updates

​Git-basierte Blueprints

​Build-Probleme beheben

​Schritt „Initialize“ fehlgeschlagen

​Repository konnte nicht geklont werden

​Maintenance-Schritt fehlgeschlagen

​Build-Timeout

​Fixes iterativ verbessern

​Nächste Schritte

Differentielle Builds

GitHub Actions in Blueprints

Workspaces und Monorepos

Blueprint-Referenz

Vorlagenbibliothek

Git-basierte Blueprints

Migration von der klassischen Einrichtung

Enterprise-Umgebungsverwaltung

Erste Schritte

Wie es funktioniert

Blueprint-Abschnitte

Geltungsbereich von Blueprints

Builds und Sitzungen

Der Snapshot

So funktionieren Builds

Wie Sitzungen funktionieren

Was einen Build auslöst

Build-Status

Ihre Umgebung verwalten

Repository-Zustände

Secrets

Mehrere Repositories

GitHub Actions

Monorepos

Anpinnen und automatische Updates

Git-basierte Blueprints

Build-Probleme beheben

Schritt „Initialize“ fehlgeschlagen

Repository konnte nicht geklont werden

Maintenance-Schritt fehlgeschlagen

Build-Timeout

Fixes iterativ verbessern

Nächste Schritte