Überblick über Enterprise-Umgebungen

Voraussetzungen: Dieser Leitfaden setzt Kenntnisse der deklarativen Umgebungskonfiguration voraus. Eine Einführung finden Sie unter Deklarative Umgebungskonfiguration.

Bevor Sie Umgebungen konfigurieren, stellen Sie sicher, dass Ihr SCM-Anbieter verbunden ist (Enterprise Settings > Integrationen) und jeder Organisation Zugriff auf ihre Repositories gewährt wurde (Enterprise Settings > Repository-Berechtigungen). Orgs können ihrer Umgebung keine Repos hinzufügen, bis der Zugriff ausdrücklich gewährt wurde. Weitere Details finden Sie unter Git-Integrationen.

Enterprise-Admins können eine Basisumgebung definieren, die für jede Organisation im Enterprise gilt. So haben Sie zentrale Kontrolle über die Tools, Laufzeitumgebungen und die Sicherheitsinfrastruktur, die Devin verwendet, während einzelne Orgs und Repos ihre eigene Konfiguration weiterhin darauf aufbauend anpassen können.

Die Blueprint-Hierarchie

Die Umgebungskonfiguration von Devin ist in drei Ebenen gegliedert. Jede Ebene baut auf der darüberliegenden auf:

+-----------------------------------------+
|  Enterprise Blueprint                   |
|  Python 3.12, Node 20, security tools   |
+-----------------------------------------+
|  Organization Blueprint                 |
|  private npm registry, team linting     |
+-----------------------------------------+
|  Repository Blueprint                   |
|  npm install, project-specific config   |
+-----------------------------------------+

Tier	Wer verwaltet es	Geltungsbereich
Enterprise	Enterprise-Admins	Alle Organisationen, alle Repositories
Organization	Org-Admins	Alle Repositories in der Org
Repository	Org-Admins oder Repo-Konfig	Ein einzelnes Repository

Die Beziehung ist additiv: Org- und Repo-Blueprints bauen auf dem Enterprise-Blueprint auf, sie ersetzen ihn nicht. Bei jedem Build wird zuerst der Enterprise-Blueprint ausgeführt und legt die Ausgangsbasis fest. Anschließend wird der Org-Blueprint ausgeführt und ergänzt teamspezifische Konfigurationen. Zum Schluss wird der Blueprint jedes Repos mit projektspezifischem Setup ausgeführt. Unter Blueprint-Geltungsbereich erfahren Sie, wie Org- und Repo-Blueprints zusammenhängen.

Enterprise-Blueprint konfigurieren

Navigieren Sie zu Settings > Devins Basisumgebung, um den Enterprise-Blueprint zu definieren. Er verwendet dasselbe Format wie org- und Repo-Blueprints, mit den Abschnitten initialize, maintenance und knowledge. Enterprise- und org-Blueprints unterstützen außerdem einen Abschnitt post-build für Befehle, die ausgeführt werden, nachdem alle Repo geklont und eingerichtet wurden. Der Enterprise-Blueprint wird bei jedem Build zuerst ausgeführt, noch vor den org- und Repo-Blueprints. Das bedeutet, dass Tools und Laufzeitumgebungen, die auf Enterprise-Ebene installiert sind, für alle nachgelagerten Blueprints verfügbar sind.

Was in den Enterprise-Blueprint gehört

Der Enterprise-Blueprint ist für Tools und Konfigurationen vorgesehen, die jede Organisation benötigt. Häufige Anwendungsfälle:

Standard-Laufzeitumgebungen für Programmiersprachen

Legen Sie unternehmensweit feste Sprachversionen fest, damit jedes Team mit derselben Toolchain arbeitet:

initialize:
  - name: "Install Python 3.12"
    uses: github.com/actions/setup-python@v5
    with:
      python-version: "3.12"

  - name: "Install Node.js 20"
    uses: github.com/actions/setup-node@v4
    with:
      node-version: "20"

  - name: "Install Go 1.22"
    uses: github.com/actions/setup-go@v5
    with:
      go-version: "1.22"

Sicherheitstools und Compliance-Scans

Installiere Scanner und Audit-Tools, die in jedem Projekt verwendet werden müssen:

initialize:
  - name: "Install security tools"
    run: |
      npm install -g snyk
      pip install safety bandit
      curl -sfL https://raw.githubusercontent.com/aquasecurity/trivy/main/contrib/install.sh | sh

Interne CLI-Tools und Hilfsprogramme

Verteilen Sie unternehmensspezifische Tools in jede Umgebung:

initialize:
  - name: "Install internal CLI"
    run: |
      curl -L https://internal.example.com/cli/latest/linux-amd64 \
        -o /usr/local/bin/internal-cli
      chmod +x /usr/local/bin/internal-cli

Konfiguration gemeinsamer Paket-Registries

Konfigurieren Sie Paketmanager für Ihre internen Registries:

initialize:
  - name: "Configure internal registries"
    run: |
      npm config set registry https://npm.internal.example.com/
      pip config set global.index-url https://pypi.internal.example.com/simple/

Einrichtung von Unternehmens-Proxy und Zertifikaten

Installieren Sie Unternehmens-CA-Zertifikate und konfigurieren Sie die Proxyeinstellungen:

initialize:
  - name: "Install corporate certificates"
    run: |
      cp "$FILE_CORPORATE_CA_CERT" /usr/local/share/ca-certificates/corporate-ca.crt
      update-ca-certificates
      echo 'export NODE_EXTRA_CA_CERTS=/usr/local/share/ca-certificates/corporate-ca.crt' >> ~/.bashrc

Wie die Ebenen zusammenwirken

Während eines Builds werden die Schritte jeder Ebene in einer festen Reihenfolge ausgeführt. Die Ausgabe früherer Ebenen steht den nachfolgenden Ebenen zur Verfügung. Auf Enterprise-Ebene installierte Tools können in org- und Repo-Blueprints ohne erneute Installation verwendet werden. Ein Build erstellt in dieser Reihenfolge einen neuen Snapshot:

1. Enterprise blueprint (runs in ~):
   a. initialize
   b. maintenance
2. Organization blueprint (runs in ~):
   a. initialize
   b. maintenance
3. 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. maintenance
5. post-build (org- and enterprise-level; runs in ~)
6. Health check, then snapshot is saved

post-build-Schritte werden ausgeführt, nachdem jedes Repo geklont und eingerichtet wurde, sodass sie die vollständig aufgebaute Umgebung überprüfen können. Ein Exit-Code ungleich null in einem post-build-Schritt führt dazu, dass der Build fehlschlägt und kein Snapshot erstellt wird. Siehe post-build in der Blueprint-Referenz. Ebenen sind additiv: Repo-Blueprints können Tools verwenden, die über den Org- oder Enterprise-Blueprint 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 Zeitlimit von 1 Stunde. knowledge-Einträge aus allen Ebenen werden gesammelt und Devin zur Verfügung gestellt. Wenn mehrere Ebenen einen knowledge-Eintrag mit demselben Namen definieren, werden alle berücksichtigt. Sie überschreiben sich nicht gegenseitig.

Enterprise-Secrets

Enterprise-Admins können Secrets auf Enterprise-Ebene definieren. Diese Secrets stehen während jedes Builds und jeder Sitzung in allen Organisationen als Umgebungsvariablen zur Verfügung – sowohl in Blueprint-Schritten auf Enterprise-, org- als auch auf Repo-Ebene. Verwenden Sie Enterprise-Secrets für Anmeldedaten, die im gesamten Unternehmen gemeinsam genutzt werden:

Token für interne Package-Registries
Authentifizierung für Unternehmens-Proxys
Gemeinsame API-Schlüssel für interne Dienste
Lizenzschlüssel für Enterprise-Tools

Enterprise-Secrets werden im Tab Secrets innerhalb des Editors für den Enterprise-Blueprint verwaltet. Navigieren Sie zu Settings > Devins Basisumgebung und wechseln Sie zum Tab Secrets, um unternehmensweite Secrets zusammen mit Ihrer Blueprint-Konfiguration zu verwalten.

Zum Verwalten von Enterprise-Secrets ist die Berechtigung ManageAccountResources erforderlich.

Wenn ein org-Secret denselben Namen wie ein Enterprise-Secret hat, hat das org-Secret Vorrang. So können einzelne Organisationen bei Bedarf unternehmensweite Standardeinstellungen überschreiben.

Unternehmensweite Rebuilds

Enterprise-Admins können einen Rebuild auslösen, der auf alle Organisationen angewendet wird. Das ist nützlich, wenn:

Sie den Enterprise-Blueprint aktualisieren (z. B. Python von 3.11 auf 3.12 aktualisieren)
Sie ein Enterprise-Secret rotieren
Sie nach einem Sicherheitspatch alle Umgebungen aktualisieren müssen

Lösen Sie einen unternehmensweiten Rebuild unter Settings > Devins Basisumgebung aus. Der Build jeder Organisation wird mit dem aktualisierten Enterprise-Blueprint ausgeführt, gefolgt von den jeweiligen Org- und Repo-Blueprints.

Unternehmensweite Rebuilds berücksichtigen die Build-Warteschlange jeder Org. Wenn für eine Org bereits ein Build ausgeführt wird, wird der unternehmensweit ausgelöste Rebuild dahinter eingereiht. Wenn bereits ein Build in der Warteschlange steht, wird er abgebrochen und durch den unternehmensweit ausgelösten ersetzt.

Rollout über Organisationen hinweg verwalten

Der Enterprise-Admin steuert, welche Organisationen die deklarative Konfiguration statt des klassischen Umgebungs-Setups verwenden. Die Seite Rollout bietet einen Überblick über den Einführungsstand in allen Organisationen und ermöglicht die schrittweise Migration von Organisationen. Eine detaillierte Anleitung zu den Rollout-Status, organisationsspezifischen Überschreibungen und einem Playbook für die schrittweise Migration finden Sie unter Migration Ihres Enterprise.

Szenarien: Mit ACME Corp wachsen — ausgearbeitete Beispiele für die Wahl einer Ebene, während ein Unternehmen wächst
Migration Ihres Enterprise
Best Practices
Blueprint-Referenz
Deklarative Umgebungskonfiguration

Erste Schritte

Bereitstellung

Umgebungsverwaltung

Integrationen

Sicherheit & Zugriff

Anwendungsfälle & Tutorials

Überblick über Enterprise-Umgebungen

Die Blueprint-Hierarchie

Enterprise-Blueprint konfigurieren

Was in den Enterprise-Blueprint gehört

Standard-Laufzeitumgebungen für Programmiersprachen

Sicherheitstools und Compliance-Scans

Interne CLI-Tools und Hilfsprogramme

Konfiguration gemeinsamer Paket-Registries

Einrichtung von Unternehmens-Proxy und Zertifikaten

Wie die Ebenen zusammenwirken

Enterprise-Secrets

Unternehmensweite Rebuilds

Rollout über Organisationen hinweg verwalten

​Die Blueprint-Hierarchie

​Enterprise-Blueprint konfigurieren

​Was in den Enterprise-Blueprint gehört

​Standard-Laufzeitumgebungen für Programmiersprachen

​Sicherheitstools und Compliance-Scans

​Interne CLI-Tools und Hilfsprogramme

​Konfiguration gemeinsamer Paket-Registries

​Einrichtung von Unternehmens-Proxy und Zertifikaten

​Wie die Ebenen zusammenwirken

​Enterprise-Secrets

​Unternehmensweite Rebuilds

​Rollout über Organisationen hinweg verwalten

​Verwandte Seiten

Die Blueprint-Hierarchie

Enterprise-Blueprint konfigurieren

Was in den Enterprise-Blueprint gehört

Standard-Laufzeitumgebungen für Programmiersprachen

Sicherheitstools und Compliance-Scans

Interne CLI-Tools und Hilfsprogramme

Konfiguration gemeinsamer Paket-Registries

Einrichtung von Unternehmens-Proxy und Zertifikaten

Wie die Ebenen zusammenwirken

Enterprise-Secrets

Unternehmensweite Rebuilds

Rollout über Organisationen hinweg verwalten

Verwandte Seiten