Blueprints für Devin-Umgebungen

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 Organisation in Enterprise Settings > Repository Permissions Zugriff auf ihre Repositories gewähren.

Ein Blueprint ist das Format, mit dem Devin eine Umgebung beschreibt: die zu installierenden Tools, die zu verwaltenden Abhängigkeiten und die Befehle, die Devin kennen sollte. Devin kann aus Ihrem Repository einen Blueprint erstellen, und Sie können ihn prüfen oder bearbeiten, wenn Sie mehr Kontrolle über das Setup wünschen.

Devin erledigt das (empfohlen)
Manuelle Einrichtung

Am besten für die meisten Nutzer geeignet. Devin untersucht Ihr Repository, ermittelt die benötigten Tools, Laufzeitumgebungen und Abhängigkeiten und erstellt den Blueprint für Sie. Sie prüfen und genehmigen das vorgeschlagene Setup, bevor der Build startet.

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 Repository ein.”

Prüfen und freigeben

Devin schlägt anhand der gefundenen Informationen einen Blueprint vor. In Ihrer Timeline sehen Sie suggestion cards. Prüfen Sie die vorgeschlagenen Tools, Abhängigkeiten und Befehle und klicken Sie dann auf Approve.

Build starten und überprüfen

Sobald Sie die Vorschläge genehmigen, wird ein Build ausgeführt und erstellt einen Snapshot. Starten Sie eine neue Sitzung, um daraus zu starten, und bitten Sie Devin dann, Ihre Lint- oder Testbefehle auszuführen, um zu bestätigen, dass alles funktioniert.

Sehen Sie sich im Environment-Hub das Video und die Übersicht zur Einrichtung mit einem Prompt an.

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 Organisation zu Settings > Environment > Blueprints.Wenn Sie diese Option nicht sehen, wenden Sie sich an Ihren Enterprise-Administrator, um zu bestätigen, dass Umgebungs-Blueprints für Ihre Organisation aktiviert sind.

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. Die Build-Dauer hängt davon ab, wie viele Repositories Sie konfiguriert haben und wie viel Arbeit Ihre Blueprints ausführen. Verfolgen Sie daher 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 erläutert, wie der erzeugte Blueprint funktioniert und wie Sie ihn bearbeiten, wenn Sie mehr Kontrolle wünschen.

Sehen Sie die vollständige Umsetzung

Szenarien: Wachstum mit ACME Corp — ein Repository, dann mehrere Repositories mit gemeinsamen Abhängigkeiten, dann mehrere Organisationen. Ausgearbeitete Blueprints für jede Phase und Hinweise dazu, wie Sie entscheiden, zu welcher Ebene etwas gehört.

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, Repositorys klont und einen Snapshot erstellt	`docker build`
Snapshot	Ein eingefrorenes, bootfähiges Image 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 Kernabschnitte sowie einen post-build-Block für Blueprints auf Organisations-/Enterprise-Ebene und einen optionalen clone-Block für Blueprints auf Repository-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.
`post-build`	Die vollständig zusammengesetzte Umgebung validieren (nur Organisation/Enterprise)	Während Builds, nachdem alle Repository geklont und eingerichtet wurden. Ein Exit-Code ungleich null lässt den Build fehlschlagen.
`clone`	Standardvorgaben für das Klonen des Repositorys überschreiben (nur auf Repository-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. post-build (nur auf Organisations- und Enterprise-Ebene) wird ausgeführt, nachdem jedes Repository geklont und eingerichtet wurde, direkt bevor der Snapshot gespeichert wird. Verwende es, um die zusammengesetzte Umgebung zu überprüfen — z. B. ob erforderliche Tools installiert sind oder ein Repository-übergreifender Smoke-Test erfolgreich ist. Ein Exit-Code ungleich null lässt den Build fehlschlagen, sodass kein Snapshot bereitgestellt wird, ohne deine Prüfungen zu bestehen. Siehe Blueprint-Referenz → post-build. clone (nur auf Repository-Ebene) überschreibt Standardvorgaben, die Devin beim Klonen des Repositorys 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 Repositorys gemeinsam genutzt werden: Laufzeitumgebungen, Paketmanager, Docker-Authentifizierung
Repository	Settings > Environment > Blueprints > [Repo-Name]	Projektspezifisches Setup: `npm install`, Lint-/Test-/Build-Befehle

Blueprints sind additiv: Repository-Blueprints bauen auf dem Organisations-Blueprint auf. Das maintenance eines Repositorys kann Tools verwenden, die im initialize der Organisation installiert wurden. Wenn nur ein Repository ein Tool benötigt, fügen Sie es dem Blueprint dieses Repositorys hinzu. Wenn es in jedem Repository benötigt wird, fügen Sie es dem Organisations-Blueprint hinzu. Bei Monorepos kann ein Repository einen Root-Blueprint sowie Workspace-Blueprints pro Unterverzeichnis haben, jeweils mit eigenen Abschnitten für initialize, maintenance und knowledge sowie einem eigenen Arbeitsverzeichnis. Anleitungen zur Einrichtung und Beispiele finden Sie unter Workspaces und Monorepos. Konkrete Beispiele dafür, wie Sie mit wachsender Codebasis die passende Ebene wählen, finden Sie unter Szenarien: Wachstum mit ACME Corp.

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, Repositorys und Abhängigkeiten vorinstalliert sind. Alle konfigurierten Repositorys 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 der Reihe nach ausgeführt werden:

1. Enterprise Blueprint, falls konfiguriert (läuft in ~):
   a. initialize
   b. maintenance
2. Organisations-Blueprint (läuft in ~):
   a. initialize
   b. maintenance
3. Alle Repositorys klonen (bis zu 10 gleichzeitig).
   Der Blueprint jedes Repositorys kann die Standardwerte für das Klonen über den
   `clone`-Block überschreiben (Branch/Tag, Tiefe, Submodule, LFS usw.).
4. Für jedes konfigurierte Repository, in der in den Settings angezeigten Reihenfolge
   (läuft in ~/repos/<repo-name>):
   a. initialize
   b. maintenance
5. post-build-Schritte (zuerst die des Organisations-Blueprints, dann die des Enterprise Blueprints; läuft in ~)
6. Integritätsprüfung, danach wird der Snapshot gespeichert

Schichten sind additiv: Repository-spezifische Befehle können Tools verwenden, die im Organisations- oder Enterprise-Blueprint installiert wurden. Untergeordnete Ebenen können die Konfiguration höherer Ebenen nicht überschreiben. Die Build-Dauer skaliert mit der Anzahl konfigurierter Repositorys und dem Umfang der von Ihren Blueprints ausgeführten Arbeit. Einzelne Schritte haben ein Zeitlimit 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 Repositorys abgerufen.
maintenance-Befehle (Enterprise-, organisations- und repository-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 Repositorys werden in Devins Kontext geladen.

Knowledge ist repository-spezifisch. Wenn Sie 5 Repositorys konfiguriert haben, sieht Devin nur die Knowledge-Einträge des Repositorys, 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
Queued	Der Build wurde akzeptiert und wartet auf eine Maschine.
Building	Die Setup-Schritte werden auf der Build-Maschine ausgeführt.
Success	Alle Schritte wurden abgeschlossen. Der Snapshot ist bereit.
Partial	Einige Schritte auf Repository-Ebene sind fehlgeschlagen, aber der Snapshot ist nutzbar. Erfolgreiche Repositorys funktionieren normal; bei fehlgeschlagenen Repositorys müssen die Blueprints korrigiert werden.
Failed	Der Snapshot ist nicht nutzbar. Dies tritt auf, wenn ein Organization- oder Enterprise-Blueprint fehlschlägt (einschließlich der zugehörigen Post-Build-Schritte), ein Repository nicht geklont werden kann oder die Maschine die abschließenden Integritätsprüfungen nicht besteht.
Cancelled	Durch einen neueren Build ersetzt oder manuell abgebrochen.

Ein teilweiser Build erzeugt dennoch einen funktionierenden Snapshot. Jedes Repository wurde geklont, sodass der gesamte Quellcode in der Sitzung verfügbar ist — lediglich die Setup-Schritte der fehlgeschlagenen Blueprints wurden nicht ausgeführt. Wenn eines von fünf Repositorys einen fehlerhaften Blueprint hat, sind die anderen vier vollständig eingerichtet, und Devin kann das fünfte weiterhin lesen und damit arbeiten.

Build schlägt fehl? Eine Schritt-für-Schritt-Anleitung zum Debugging finden Sie unter Fehlerbehebung bei Builds.

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“ Repository wird in den Snapshot geklont, damit Devin auf den Code zugreifen kann, hat aber keine benutzerdefinierten Setup-Befehle. Ein „konfiguriertes“ Repository 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 Repository erhält eine eigene Blueprint. Während eines Builds werden alle Repositories im selben Snapshot eingerichtet, in separate Verzeichnisse geklont, und die Abhängigkeiten werden jeweils unabhängig voneinander installiert. Wenn zwei Repositories 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 Blueprint-Schritt gilt ein Timeout von 1 Stunde. Für Repository-Klone gilt ein separater Timeout von 2 Stunden. 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

Szenarien: Wachstum mit ACME Corp

Durchgearbeitete Beispiele: ein Repository, dann mehrere Repositories mit gemeinsam genutzten Abhängigkeiten, dann mehrere Organisationen.

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 Repository als .devin/blueprint.yaml und synchronisieren Sie sie über API oder UI.

Enterprise-Umgebungsverwaltung

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

​Erste Schritte

Sehen Sie die vollständige Umsetzung

​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

Szenarien: Wachstum mit ACME Corp

Differentielle Builds

GitHub Actions in Blueprints

Workspaces und Monorepos

Blueprint-Referenz

Vorlagenbibliothek

Git-basierte Blueprints

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