Skip to main content
Die deklarative Konfiguration (Blueprints) ist die nächste Generation des Umgebungs-Setups: versionskontrolliert, kombinierbar und mit automatischen Updates. Diese Anleitung führt Sie durch die Migration vom klassischen interaktiven Assistenten.

​
Warum migrieren?

Mit dem klassischen Setup-Assistenten ist Devins Umgebung ein manuell konfigurierter Snapshot, der mit der Zeit vom gewünschten Zustand abweichen kann. Abhängigkeiten veralten, Konfigurationsänderungen erfordern ein erneutes Ausführen des Assistenten, und es gibt keinen Versionsverlauf. Die deklarative Konfiguration löst diese Probleme:
  • Automatische Updates: Blueprints werden neu erstellt, wenn sich Ihr Repo ändert, sodass Abhängigkeiten aktuell bleiben
  • Versionskontrolliert: Ihre Umgebungskonfiguration wird zusammen mit Ihrem Code versioniert – mit vollständigem Verlauf
  • Kombinierbar: Enterprise-, Org- und Repo-Blueprints lassen sich sauber miteinander kombinieren
  • Reproduzierbar: Jeder Build erzeugt aus demselben Blueprint dasselbe Ergebnis
  • Schnellere Sitzungen: Snapshots werden vorab erstellt, Repos geklont und Abhängigkeiten installiert, sodass Sitzungen direkt einsatzbereit starten
Wir empfehlen, auf deklarative Konfiguration umzustellen, sobald Sie bereit sind. Ihr klassisches Setup funktioniert in der Zwischenzeit weiterhin.

​
Bevor Sie beginnen

Suchen Sie auf der Seite Machine Configuration (der klassischen Einrichtungsseite) nach einem Banner mit dem Text „Zu Devins neuer v2-Umgebung wechseln“. Wenn es angezeigt wird, ist Ihre Organisation dafür berechtigt.Wenn das Banner nicht angezeigt wird, ist die deklarative Konfiguration für Ihre Organisation noch nicht aktiviert. Die Funktion wird schrittweise ausgerollt. Wenden Sie sich an Ihren Enterprise-Admin oder an den Support.
Für die Migration sind Org-Admin-Berechtigungen (ManageOrgSettings) erforderlich. Wenn Sie kein Org-Admin sind, wird auf der Migrationsseite die Meldung „Admin-Zugriff erforderlich“ angezeigt.
Ja. Ihr vorhandener Snapshot bleibt vollständig erhalten. Sie können jederzeit zurückwechseln, und Ihre Organisation wechselt sofort wieder zum vorherigen Snapshot. Es geht nichts verloren.

​
Schritte zur Migration

​
1. Zur Migrationsseite wechseln

Navigieren Sie zu Settings > Environment migration oder klicken Sie auf dem Banner auf der Seite Machine Configuration auf Get started.

​
2. Deklarative Konfiguration aktivieren

Klicken Sie auf Für die Organisation aktivieren. Dadurch wird Ihre Organisation so umgestellt, dass für neue Sitzungen blueprintbasierte Snapshots verwendet werden.
Dies hat keine Auswirkungen auf Ihren vorhandenen Snapshot. Er bleibt erhalten, falls Sie die Änderungen rückgängig machen müssen.

​
3. Lassen Sie Devin Ihre Blueprints erstellen

Devin erledigt die Arbeit für Sie. Klicken Sie auf Start migration und wählen Sie die Repositories aus, die Sie zuerst migrieren möchten. Sie müssen nicht alles auf einmal migrieren. Beginnen Sie mit Ihren meistgenutzten Repos. Wenn Sie die Migration starten, erstellt Devin zwei Sitzungen:
  • Eine Hauptsitzung, die in der neuen deklarativen Umgebung läuft und die Blueprints erstellt
  • Eine Hilfssitzung, die auf Ihrem vorhandenen Snapshot läuft und die Devin verwendet, um zu ermitteln, was derzeit installiert ist (Sprachversionen, Systempakete, laufende Dienste usw.)
Devin untersucht Ihren vorhandenen Snapshot, ermittelt, welche Tools und Abhängigkeiten installiert sind, und erstellt die entsprechende Blueprint-Konfiguration. Die Ergebnisse werden auf Ihrer Seite Environment configuration angezeigt.
Ihr vorhandener Snapshot ist eine „Blackbox“ aus allem, was Sie im Laufe der Zeit konfiguriert haben. Devin untersucht diesen Snapshot, erfasst, was installiert ist, und hält es automatisch in einem reproduzierbaren Blueprint fest.

​
4. Überprüfen und anpassen

Nachdem Devin die Blueprints generiert hat:
  1. Gehen Sie zu Settings > Environment configuration, um zu sehen, was generiert wurde
  2. Prüfen Sie den Build-Status. Er sollte Success anzeigen.
  3. Starten Sie eine Testsitzung, um sicherzustellen, dass alles funktioniert:
    • Stellen Sie sicher, dass Repos geklont wurden und Abhängigkeiten installiert sind
    • Versuchen Sie, Ihre Lint-, Test- und Build-Befehle auszuführen
    • Vergewissern Sie sich, dass alle benutzerdefinierten Tools oder Laufzeitumgebungen verfügbar sind
Falls etwas fehlt, bearbeiten Sie den Blueprint direkt. Sie können initialize-Schritte, maintenance-Befehle oder knowledge-Einträge hinzufügen.

​
Rückgängig machen

Falls etwas nicht funktioniert, können Sie jederzeit zurückkehren:
  1. Gehen Sie zu Settings > Environment migration
  2. Klicken Sie auf Zum klassischen Setup zurückkehren
  3. Ihre Organisation wechselt sofort wieder zum vorherigen Snapshot
Ihr vorhandener Snapshot bleibt vollständig erhalten. Es geht nichts verloren. Sie können die Migration jederzeit erneut versuchen, wenn Sie bereit sind.

​
Zuordnung klassischer Einrichtungsschritte zu Blueprints

Wenn Sie Ihr Blueprint lieber manuell schreiben (oder die Zuordnung nachvollziehen möchten), sehen Sie hier, wie die Schritte des klassischen Assistenten Blueprints entsprechen:
Klassischer EinrichtungsschrittBlueprint-ÄquivalentHinweise
Git pullAutomatischBlueprints übernehmen Git-Clone und -Pull automatisch
SecretsSecrets-Bereich in der UIIn Settings > Environment configuration konfigurieren
Abhängigkeiten installiereninitializeEinmaliges Setup: Laufzeitumgebungen, Systempakete, globale Tools
Abhängigkeiten verwaltenmaintenanceWiederkehrendes Setup pro Sitzung: npm install, pip install usw.
Lintknowledge (name: lint)Nur als Referenz, wird bei Builds nicht ausgeführt
Testknowledge (name: test)Nur als Referenz, wird bei Builds nicht ausgeführt
App startenknowledge (name: dev-server)Nur als Referenz, wird bei Builds nicht ausgeführt
Zusätzliche HinweiseknowledgeFreitext-Einträge für Devin

​
Beispiel

Klassisches Setup:
  • Abhängigkeiten installieren: nvm use 20 && npm install
  • Abhängigkeiten pflegen: npm install
  • Linting: npm run lint
  • Testen: npm test
  • App starten: npm run dev
Entsprechender Blueprint: 
initialize: |
  curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash
  source ~/.bashrc
  nvm install 20

maintenance: |
  npm install

knowledge:
  - name: lint
    contents: npm run lint
  - name: test
    contents: npm test
  - name: dev-server
    contents: npm run dev

​
Fehlerbehebung

Prüfe die Build-Logs auf den genauen Fehler. Häufige Ursachen:
  • Ein Befehl, der im klassischen Setup-Terminal funktioniert hat, funktioniert im Build-Kontext nicht (z. B. interaktive Abfragen, die -y-Flags benötigen)
  • Fehlende Secrets (stelle sicher, dass Secrets im Secrets-Bereich des Blueprint-Editors konfiguriert sind)
  • Vergleiche deine Blueprint-Befehle mit deinen ursprünglichen Befehlen, um Unterschiede zu erkennen
Stelle sicher, dass dein Abschnitt maintenance dieselben Befehle zur Installation von Abhängigkeiten enthält wie der klassische Schritt Maintain Dependencies. Befehle wie npm install oder pip install -r requirements.txt gehören in maintenance, nicht in initialize.
Stelle sicher, dass dein Abschnitt knowledge Einträge mit den Namen lint und test sowie die richtigen Befehle enthält. Devin sucht nach diesen Namen, wenn es seine Arbeit überprüft.
Wenn dein klassisches Setup ~/.bashrc, ~/.profile oder andere Shell-Konfigurationen geändert hat, verschiebe sie in initialize:
initialize: |
  echo 'export PATH="$HOME/.local/bin:$PATH"' >> ~/.bashrc
  echo 'export NODE_ENV=development' >> ~/.bashrc
Blueprints führen git clone während des Builds automatisch aus. Wenn Repos nicht geklont werden, prüfe, ob sie auf der Seite für die Environment configuration hinzugefügt wurden und ob Devin über deine Git-Integration Zugriff hat.