> ## 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.

# Überblick über Enterprise-Umgebungen

> Unternehmensweite Verwaltung von Umgebungen: Blueprint-Hierarchie, Konfiguration von Enterprise-Blueprints, Secrets und unternehmensweite Rebuilds.

<Info>
  **Voraussetzungen:** Dieser Leitfaden setzt Kenntnisse der deklarativen Umgebungskonfiguration voraus. Eine Einführung finden Sie unter [Deklarative Umgebungskonfiguration](/de/onboard-devin/environment/blueprints).
</Info>

<Warning>
  **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](/de/enterprise/integrations/git-integrations).
</Warning>

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.

<div id="the-blueprint-hierarchy">
  ## Die Blueprint-Hierarchie
</div>

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](/de/onboard-devin/environment/blueprints#blueprint-scope) erfahren Sie, wie Org- und Repo-Blueprints zusammenhängen.

<div id="configuring-the-enterprise-blueprint">
  ## Enterprise-Blueprint konfigurieren
</div>

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`](/de/onboard-devin/environment/blueprint-reference#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.

<div id="what-to-put-in-the-enterprise-blueprint">
  ## Was in den Enterprise-Blueprint gehört
</div>

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

<div id="standard-language-runtimes">
  ### Standard-Laufzeitumgebungen für Programmiersprachen
</div>

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

```yaml theme={null}
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"
```

<div id="security-tools-and-compliance-scanning">
  ### Sicherheitstools und Compliance-Scans
</div>

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

```yaml theme={null}
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
```

<div id="internal-cli-tools-and-utilities">
  ### Interne CLI-Tools und Hilfsprogramme
</div>

Verteilen Sie unternehmensspezifische Tools in jede Umgebung:

```yaml theme={null}
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
```

<div id="shared-package-registry-configuration">
  ### Konfiguration gemeinsamer Paket-Registries
</div>

Konfigurieren Sie Paketmanager für Ihre internen Registries:

```yaml theme={null}
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/
```

<div id="corporate-proxy-and-certificate-setup">
  ### Einrichtung von Unternehmens-Proxy und Zertifikaten
</div>

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

```yaml theme={null}
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
```

<div id="how-tiers-interact">
  ## Wie die Ebenen zusammenwirken
</div>

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`](/de/onboard-devin/environment/blueprint-reference#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.

<div id="enterprise-secrets">
  ## Enterprise-Secrets
</div>

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.

<Info>Zum Verwalten von Enterprise-Secrets ist die Berechtigung **ManageAccountResources** erforderlich.</Info>

<Warning>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.</Warning>

<div id="enterprise-wide-rebuilds">
  ## Unternehmensweite Rebuilds
</div>

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.

<Info>
  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.
</Info>

<div id="managing-rollout-across-organizations">
  ## Rollout über Organisationen hinweg verwalten
</div>

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](/de/enterprise/environment-management/rollout).

<div id="related-pages">
  ## Verwandte Seiten
</div>

* [Ihr Enterprise migrieren](/de/enterprise/environment-management/rollout)
* [Best Practices](/de/enterprise/environment-management/best-practices)
* [Blueprint-Referenz](/de/onboard-devin/environment/blueprint-reference)
* [Deklarative Umgebungskonfiguration](/de/onboard-devin/environment/blueprints)
