> ## Documentation Index > Fetch the complete documentation index at: https://docs.devin.ai/llms.txt > Use this file to discover all available pages before exploring further. # Deklarative Konfiguration > Definieren Sie Ihre Umgebung in YAML-Blueprints. Builds werden automatisch ausgeführt, um Snapshots zu erstellen, von denen jede Sitzung bootet.
## 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](/de/onboard-devin/environment#before-you-start) 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](/de/onboard-devin/environment/migration). 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. Öffnen Sie eine neue Sitzung und bitten Sie Devin, das Repository zu konfigurieren. Zum Beispiel: *"Richte deine Umgebung für dieses Repo ein."* Devin schlägt einen Blueprint vor. In Ihrer Timeline sehen Sie **suggestion cards**. Prüfen Sie sie und klicken Sie auf **Approve**. 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. 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](/de/onboard-devin/environment/migration) erfahren Sie, wie Sie loslegen. 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. Klicken Sie auf ein Repository, um den Blueprint-Editor zu öffnen. Hier ist ein einfaches Beispiel: ```yaml theme={null} 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](/de/onboard-devin/environment/templates). 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**. 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](/de/onboard-devin/environment/blueprint-reference#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](/de/product-guides/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](/de/onboard-devin/environment/blueprint-reference).
### 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](/de/enterprise/environment-management/overview).
## 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/): 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: 1. Der neueste Code wird für die relevanten Repos abgerufen. 2. `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. 3. 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](#troubleshooting-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. ```yaml theme={null} 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](/de/onboard-devin/environment/blueprint-reference#environment-variables-and-secrets).
### 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. ```yaml theme={null} 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](/de/onboard-devin/environment/github-actions).
### 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](/de/onboard-devin/environment/workspaces) 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](/de/onboard-devin/environment/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
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
Beschleunigen Sie Builds, indem Sie nur die Workspaces neu erstellen, deren Blueprints geändert wurden. Verwenden Sie GitHub Actions, um Sprachen, Tools und SDKs zu installieren, ohne Shell-Skripte schreiben zu müssen. Subshells, Workspace-Geltungsbereiche und Knowledge-Einträge für Repositories mit mehreren Paketen. Vollständige Feldreferenz: Schritttypen, Umgebungsvariablen, Secrets und Dateianhänge. Blueprints zum Kopieren und Einfügen für Python, Node.js, Go, Java, Ruby, Rust und erweiterte Muster. Speichern Sie Blueprints in Ihrem Repo als `.devin/blueprint.yaml` und synchronisieren Sie sie über API oder UI. Schritt-für-Schritt-Anleitung für den Wechsel vom interaktiven Assistenten zu deklarativen Blueprints. Unternehmensweite Umgebungsverwaltung: 3-stufige Hierarchie, Secrets und organisationsübergreifende Konfiguration.