Sie müssen dies nicht von Hand schreiben. Am einfachsten richten Sie Ihre Umgebung ein, indem Sie eine Devin-Sitzung starten und Devin bitten, das Repo zu konfigurieren. Devin analysiert das Projekt, installiert Abhängigkeiten und schlägt eine Konfiguration vor — Sie klicken in Ihrer Timeline auf den Vorschlagskarten auf Approve.Diese Anleitung ist für Fälle gedacht, in denen Sie verstehen möchten, was Devin erstellt hat, die Konfiguration anpassen oder eine Konfiguration von Grund auf neu schreiben möchten.
Devin läuft auf einer eigenen VM. Jede Sitzung wird von einem Maschinenabbild gestartet — einem gespeicherten Snapshot mit Ihren vorinstallierten Tools, Repos und Dependencies. Sie legen fest, was in dieses Abbild aufgenommen wird, indem Sie Ihre Umgebungskonfiguration unter Settings > Devin’s Environment bearbeiten.
Verwenden Sie initialize für alles, was lange dauert oder nur einmal erfolgen muss: das Installieren von Paketmanagern, globalen CLI-Tools, das Kompilieren nativer Abhängigkeiten oder das Hinzufügen von Systempaketen.Die Ergebnisse werden im Maschinenabbild gespeichert und beim Start der Sitzung nicht erneut ausgeführt.
Die mehrzeilige Zeichenfolge wird als einzelnes Bash-Skript mit set -e ausgeführt, sodass jede fehlschlagende Zeile den Build abbricht. Verwenden Sie \ zur Zeilenfortsetzung oder wechseln Sie zur Erweiterten Form für benannte Schritte, die einzeln im Build-Log angezeigt werden.
Die Secrets-Datei wird entfernt, bevor das Maschinenabbild gespeichert wird. Wenn ein Befehl in initialize einen geheimen Wert in eine Konfigurationsdatei schreibt (z. B. ein Auth-Token in .npmrc), kann dieser Wert im Abbild erhalten bleiben — was ein Sicherheitsrisiko ist. Legen Sie Schritte, die Anmeldedaten schreiben, stattdessen in maintenance, wo Secrets in jeder Sitzung neu geladen werden.
Verwenden Sie die Listenform, wenn Sie benannte Schritte benötigen. Benannte Schritte machen Build-Logs leichter zu debuggen — wenn etwas fehlschlägt, sehen Sie, welcher Schritt betroffen ist, statt nur eine Zeilennummer.
Um Umgebungsvariablen für nachfolgende Schritte festzulegen, schreiben Sie Zeilen im Format KEY=VALUE in die Datei $ENVRC (ähnlich wie bei GitHub Actions’ $GITHUB_ENV). Alle in $ENVRC geschriebenen Variablen werden für nachfolgende Schritte und die Devin-Sitzung automatisch exportiert.
Verwenden Sie maintenance, um Abhängigkeiten aktuell zu halten und Konfigurationsdateien für Anmeldedaten zu schreiben.Es wird während des Builds (nach initialize) und zu Beginn jeder Sitzung, nach dem Abrufen des neuesten Codestands, ausgeführt. Da es bei jedem Sitzungsstart ausgeführt wird, sollten Befehle schnell und inkrementell sein.
Verwenden Sie npm install statt npm ci.npm ci löscht node_modules und installiert bei jedem Durchlauf alles von Grund auf neu. npm install führt dagegen eine inkrementelle Aktualisierung durch, die deutlich schneller ist, wenn sich die Abhängigkeiten nicht geändert haben.
Jeder Schritt, der Secrets in Konfigurationsdateien (.npmrc, settings.xml, pip.conf) schreibt, gehört in maintenance, nicht in initialize. Dadurch bleiben die Anmeldedaten zu Beginn jeder Sitzung aktuell.
Verwenden Sie knowledge für kleine Einrichtungsdetails, die Devin benötigt, um die gerade erstellte Environment tatsächlich zu nutzen — zum Beispiel den Lint-Befehl, den Testbefehl oder wie der Dev-Server gestartet wird.
Dies ist nicht dasselbe wie die zentrale Funktion Knowledge. Für die meisten Dinge, an die Devin sich erinnern soll — Architektur, Konventionen, Fallstricke, Team-Workflows — verwenden Sie die eigenständige Knowledge-Funktion. Sie hat umfassendere Auslöser, lässt sich leichter bearbeiten und ist der richtige Ort für allgemeinen Projektkontext.Verwenden Sie den Abschnitt knowledge in environment.yaml nur für kurze Hinweise, die direkt mit der Einrichtung der Environment in dieser Datei verknüpft sind (z. B. “der Lint-Befehl ist npm run lint”). Dieser Abschnitt ist optional, und die meisten Environments benötigen ihn nicht.
Einträge sind Referenzhinweise — sie werden nicht ausgeführt. Halten Sie sie kurz:
knowledge: - name: lint contents: | Run `npm run lint` to check for errors. Run `npm run lint:fix` to auto-fix. - name: test contents: | Run `npm test` for the full suite. Run `npm test -- --watch` during development. - name: startup contents: | Run `npm run dev` to start the dev server on port 3000.
Devin unterstützt drei Konfigurationsebenen. Die Befehle jeder Ebene sind streng additiv — sie werden während der Builds nacheinander ausgeführt, und niedrigere Ebenen können nicht überschreiben oder ändern, was höhere Ebenen konfigurieren.
Ebene
Wo konfiguriert wird
Was hier hingehört
Beispiele
Kontoweit (Enterprise)
Enterprise Settings > Environment
Infrastruktur, die alle orgs benötigen
CA-Zertifikate, Unternehmens-Proxy, VPN, DNS
Org
Settings > Environment > Organization-wide setup
Tools und Konfiguration, die in allen Repos gemeinsam genutzt werden
Laufzeitumgebungen (pnpm, uv), Docker-Authentifizierung, gemeinsam genutzte CLI-Tools
Wenn jede org in Ihrem Enterprise es benötigt → kontoweit
Wenn jedes Repo in Ihrer org es benötigt → Org
Wenn es nur ein Repo benötigt → repo-specific
Enterprise-Nutzer: Ausführliche Hinweise zur Konfiguration auf Enterprise-Ebene — Berechtigungen, Build-Kaskadierung, Multi-org-Verwaltung und Enterprise-Migration — finden Sie auf der Seite Enterprise Environment Setup.
Ihre Organisation verfügt über ein Maschinenabbild — einen Snapshot einer VM, in dem Ihre Tools, Repos und Abhängigkeiten vorinstalliert sind. Alle konfigurierten Repos werden in diesem einen Abbild geklont und eingerichtet. Jede Sitzung startet mit einer frischen Kopie.
Ein Build erstellt in dieser Reihenfolge ein neues Maschinenabbild:
1. Enterprise config (runs in ~): a. initialize b. maintenance2. Org-wide config (runs in ~): a. initialize b. maintenance3. Clone all repositories (up to 10 concurrent)4. For each configured repo, in the order shown in Settings (runs in ~/repos/<repo-name>): a. initialize b. maintenance5. Health check, then image is saved
Schichten sind additiv: repo-spezifische Befehle können Tools verwenden, die durch die Org- oder Enterprise-Konfiguration installiert wurden. Niedrigere Ebenen können nicht überschreiben, was auf einer höheren Ebene eingerichtet wurde.Builds dauern in der Regel 5–15 Minuten. Für einzelne Befehle gilt ein Timeout von 1 Stunde; für den gesamten Build gilt ein Timeout von 2 Stunden.
Alle Schritte wurden abgeschlossen. Das Maschinenabbild ist bereit.
Teilweise
Einige Repos sind fehlgeschlagen, aber der Kern-Build war erfolgreich. Sitzungen funktionieren, aber einige Repos sind möglicherweise nicht vollständig eingerichtet.
Fehlgeschlagen
Der Kern-Build ist fehlgeschlagen (z. B. Klonen fehlgeschlagen, Enterprise-/org-Einrichtung fehlgeschlagen).
Abgebrochen
Durch einen neueren Build ersetzt.
Übersprungen
Es wurden keine Konfigurationsänderungen erkannt.
Build schlägt fehl? Siehe Fehlerbehebung & FAQ für eine Schritt-für-Schritt-Anleitung zur Fehlerbehebung.
In der Environment Settings-UI werden Repositorys in drei Zuständen angezeigt:
Status
Bedeutung
Konfiguriert
Enthält eine YAML-Konfiguration für initialize/maintenance/knowledge. Vollständig im Maschinenabbild eingerichtet.
Enthalten
In das Maschinenabbild geklont, aber ohne benutzerdefinierte Konfiguration. Devin kann auf den Code zugreifen.
Verfügbar
Für die org zugänglich, aber nicht zum Environment hinzugefügt. Nicht geklont.
Enthalten vs. konfiguriert: Ein „enthaltenes“ Repo wird geklont, damit Devin auf den Code zugreifen kann, hat aber keine benutzerdefinierten Setup-Befehle. Ein „konfiguriertes“ Repo hat explizite Anweisungen für initialize/maintenance/knowledge.
Secrets sind während Builds und Sitzungen als Umgebungsvariablen verfügbar. Die Secrets-Datei wird entfernt, bevor das Maschinenabbild gespeichert wird — aber wenn ein Befehl während initialize einen Secret-Wert in eine Konfigurationsdatei ausgeschrieben hat, kann dieser ausgeschriebene Wert im Abbild erhalten bleiben. Schreiben Sie Anmeldedaten stattdessen immer in maintenance, wo sie in jeder Sitzung neu geladen werden.Weitere Informationen zur Verwaltung von Secrets finden Sie unter Secrets & Site-Cookies.
Wenn Sie mehrere Repos konfigurieren, erhält jedes eine eigene YAML-Datei in Settings. Während eines Builds werden sie alle im selben Image eingerichtet — in separate Verzeichnisse geklont und Abhängigkeiten jeweils unabhängig installiert. Während einer Sitzung sind nur die Wartung und das Knowledge des aktiven Repos relevant.Was ist, wenn zwei Repos miteinander in Konflikt stehen? Die Befehle jedes Repos werden in seinem eigenen Verzeichnis ausgeführt, daher sind Abhängigkeitskonflikte selten. Wenn zwei Repos unterschiedliche Versionen eines globalen Tools installieren oder gemeinsame Dateien (wie ~/.bashrc) ändern, setzt sich die zuletzt ausgeführte Änderung durch. Lege Installationen gemeinsam genutzter Tools in die Org-Konfiguration, um das zu vermeiden.
In einem Monorepo erstellen Sie eine einzige YAML-Datei, die alle Unterprojekte abdeckt. Verwenden Sie Subshells, um Befehle in Unterverzeichnissen auszuführen, ohne das Arbeitsverzeichnis für nachfolgende Schritte zu ändern:
Die Klammern (cd ... && ...) sind wichtig — sie führen den Befehl in einer Subshell aus, sodass das Arbeitsverzeichnis für den nächsten Schritt zurückgesetzt wird.Wann Sie eine Multi-Repo- bzw. Monorepo-Konfiguration verwenden sollten: Befindet sich der Code in einem einzigen Git-Repository, verwenden Sie eine YAML mit Subshells. Ist er auf mehrere Git-Repositories verteilt, konfigurieren Sie jedes Repo separat in Settings.
