Zum Hauptinhalt springen

​
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.
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.
1

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.”
2

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.
3

Ü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.
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:
KonzeptBeschreibungAnalogie
BlueprintEine YAML-Konfiguration, die beschreibt, was installiert werden soll und wie Devins Umgebung eingerichtet wirdDockerfile
BuildDer Prozess, der Ihr Blueprint ausführt, Repos klont und einen Snapshot erstelltdocker build
SnapshotEin eingefrorenes, bootfähiges Abbild der Umgebung, von dem Sitzungen gestartet werdenDocker-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:
AbschnittZweckWann er ausgeführt wird
initializeTools, Laufzeitumgebungen und Systempakete installierenNur während Builds. Ergebnisse werden im Snapshot gespeichert.
maintenanceProjektabhängigkeiten installieren/aktualisieren, Konfigurationen für Zugangsdaten schreibenWährend Builds + zu Beginn jeder Sitzung
knowledgeReferenzinformationen für Devin (Lint-, Test- und Build-Befehle)Wird nicht ausgeführt. Zu Sitzungsbeginn in Devins Kontext geladen.
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 und erneut zu Sitzungsbeginn nach dem Abrufen des neuesten Codes ausgeführt. Daher sollten Befehle 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.
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.
Die vollständige Feldspezifikation (Schritttypen, GitHub-Actions-Unterstützung, Umgebungsvariablen, Secrets und Dateianhänge) findest du in der Blueprint-Referenz.

​
Geltungsbereich von Blueprints

Sie können Blueprints auf zwei Ebenen definieren:
EbeneWo Sie dies konfigurierenWas Sie hier eintragen
OrganisationSettings > Environment configuration > Org-wide setupTools, die in allen Repos gemeinsam genutzt werden: Laufzeitumgebungen, Paketmanager, Docker-Authentifizierung
RepositorySettings > Environment configuration > [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, falls konfiguriert (läuft in ~):
   a. initialize
   b. maintenance
2. Org-Blueprint (läuft in ~):
   a. initialize
   b. maintenance
3. Alle Repositorys klonen (bis zu 10 gleichzeitig)
4. Für jedes konfigurierte Repo, in der Reihenfolge wie in den Settings angezeigt
   (läuft in ~/repos/<repo-name>):
   a. initialize
   b. maintenance
5. Health-Check, dann wird der Snapshot gespeichert
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:
  1. Enterprise-weite und organisationsweite maintenance-Läufe (in ~).
  2. Der neueste Code wird für die relevanten Repos abgerufen.
  3. Die maintenance dieses Repos wird erneut ausgeführt, um Änderungen an Abhängigkeiten seit dem letzten Build zu erfassen.
  4. 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

TriggerBeschreibung
Speichern eines BlueprintsErstellen, Aktualisieren oder Löschen eines Blueprints
Hinzufügen oder Entfernen eines RepositorysJede Änderung an der Repository-Liste
Hinzufügen eines Repository-SecretsNeue Secrets erfordern einen Rebuild, bevor sie verfügbar sind
Manuelles AuslösenKlicken auf Build oder Rebuild in der UI
Periodische AktualisierungAutomatisch, etwa alle 24 Stunden
Devin-VorschlagDevin 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

StatusBedeutung
SuccessAlle Schritte wurden abgeschlossen. Der Snapshot ist bereit.
PartialEinige Schritte auf Repo-Ebene sind fehlgeschlagen, aber der Snapshot ist nutzbar. Erfolgreiche Repos funktionieren normal; fehlgeschlagene Repos erfordern Korrekturen an ihren Blueprints.
FailedKritischer Fehler (die Einrichtung der org oder von Enterprise ist fehlgeschlagen). Der Snapshot ist nicht nutzbar.
CancelledWurde 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:
StatusBedeutung
KonfiguriertVerfügt über eine Blueprint mit Initialize-/Maintenance-/Knowledge-Anweisungen. Im Snapshot vollständig eingerichtet.
EnthaltenIn den Snapshot geklont, hat aber keine benutzerdefinierte Blueprint. Devin kann auf den Code zugreifen.
VerfügbarMit 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 unter Settings > Secrets 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. Schreiben Sie Anmeldedaten immer in maintenance. 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.

​
Monorepos

Erstellen Sie für ein Monorepo ein einziges Blueprint, das alle Teilprojekte abdeckt. Verwenden Sie Subshells, um Befehle in Unterverzeichnissen auszuführen: 
maintenance:
  - name: Frontend deps
    run: (cd packages/frontend && pnpm install)
  - name: Backend deps
    run: (cd packages/backend && uv sync)
Die Klammern (cd ... && ...) werden in einer Subshell ausgeführt, sodass das Arbeitsverzeichnis für den nächsten Schritt wieder zurückgesetzt wird.

​
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 Snapshot-Build-Verlauf, suchen Sie den Build (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

Git-basierte Blueprints werden derzeit nicht unterstützt. Diese Funktion ist in Kürze verfügbar. Sie können Blueprints in Ihrem Repository speichern und Builds automatisch auslösen, wenn sie geändert werden. Konfigurieren Sie Blueprints bis dahin über die UI.

​
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

  1. Prüfen Sie die Build-Logs, um den Fehler zu identifizieren
  2. Aktualisieren Sie den relevanten Blueprint
  3. Speichern Sie (ein neuer Build wird automatisch ausgelöst)
  4. Überwachen Sie die Logs des neuen Builds
  5. 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

Blueprint-Referenz

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

Vorlagenbibliothek

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

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.