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

# Szenarien: ACME Corp im Wachstum

> Wie sich die Blueprint-Konfiguration von einem einzelnen Repository über eine Anwendung mit mehreren Repositories und gemeinsamen Abhängigkeiten bis hin zu einem Enterprise mit mehreren Organisationen weiterentwickelt.

Blueprints haben drei Ebenen — Repository, Organisation und Enterprise — und die häufigste Frage ist: *In welche Ebene gehört das?*

Diese Seite beantwortet diese Frage anhand eines fiktiven Unternehmens, **ACME Corp**, in drei Wachstumsphasen. Jede Phase bringt genau ein neues Problem mit sich, und jedes Problem wird durch die jeweils nächsthöhere Ebene gelöst. Springen Sie zu der Phase, die Ihrem Unternehmen am ehesten entspricht.

| Phase                                                                                                        | Wie ACME aussieht                                                                   | Was konfiguriert wird                                         |
| ------------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------- | ------------------------------------------------------------- |
| [1. Ein Repository](#stage-1-one-repository)                                                                 | Eine einzelne Rails-Anwendung, ein Team                                             | Ein Repository-Blueprint                                      |
| [2. Mehrere Repositories, gemeinsame Abhängigkeiten](#stage-2-several-repositories-with-shared-dependencies) | Fünf Repositories, eine gemeinsame Entwicklungs-CLI, voneinander abhängige Services | Ein Organisations-Blueprint plus ein Blueprint pro Repository |
| [3. Mehrere Organisationen](#stage-3-multiple-organizations-the-enterprise-blueprint)                        | Mehrere Teams, jeweils mit eigener Organisation, plus ein Security-Team             | Ein Enterprise-Blueprint plus Blueprints pro Organisation     |

<Info>
  Die Faustregel vorweg: **Repository-Blueprints installieren Projektabhängigkeiten, Organisations-Blueprints installieren alles, was von mehr als einem Repository gemeinsam genutzt wird, und Enterprise-Blueprints installieren alles, was jede Organisation haben muss.** Die Ebenen sind additiv und werden von oben nach unten angewendet: Enterprise → Organisation → Repositories klonen → Repository.
</Info>

***

<div id="stage-1-one-repository">
  ## Phase 1: ein Repository
</div>

ACME hat ein Produkt: `acme-web`, eine Rails-Anwendung mit Postgres und Redis. Zwei Entwickler, ein Repository. Es gibt noch nichts zu teilen, daher **landet alles im Repository-Blueprint**.

Sie fügen das Repository unter **Settings > Environment > Blueprints > Add** hinzu, öffnen den zugehörigen Editor und schreiben:

```yaml acme-web (repository blueprint) theme={null}
initialize:
  - name: Install Ruby 3.3
    uses: github.com/ruby/setup-ruby@v1
    with:
      ruby-version: "3.3"

  - name: Install Postgres and Redis
    run: |
      sudo apt-get update -qq
      sudo apt-get install -y postgresql redis-server libpq-dev
      sudo systemctl enable --now postgresql redis-server
      sudo -u postgres createuser -s "$USER"

maintenance:
  - name: Install gems and prepare the database
    run: |
      bundle install
      bin/rails db:prepare

knowledge:
  - name: lint
    contents: bundle exec rubocop
  - name: test
    contents: bundle exec rspec
  - name: startup
    contents: bin/rails server -p 3000
```

Das ist die gesamte Konfiguration. Sie speichern sie, ein Build wird ausgeführt, und jede Sitzung startet mit installiertem Ruby, laufendem Postgres, installierten Gems und ausgeführter Datenbankmigration.

**Warum noch kein Organisations-Blueprint?** Ein Organisations-Blueprint, der nur für ein Repository verwendet wird, ist bloß eine zusätzliche Abstraktionsebene. Warten Sie, bis ein zweites Repository dasselbe braucht.

<Tip>
  ACME hat das nicht von Hand verfasst. Sie haben Devin *"Richte deine Umgebung für dieses Repository ein"* gefragt, die Vorschlagskarte geprüft und auf **Approve** geklickt. Siehe [Erste Schritte](/de/onboard-devin/environment/blueprints#getting-started).
</Tip>

***

<div id="stage-2-several-repositories-with-shared-dependencies">
  ## Phase 2: mehrere Repositories mit gemeinsamen Abhängigkeiten
</div>

Zwei Jahre später hat ACME fünf Repositories:

| Repository      | Was es ist                                                                                                                                                                                                             |
| --------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `acme-devtools` | Eine CLI (`acme`), die Container startet, Services miteinander verbindet und lokale Hostnames bereitstellt (`acme.local`, `portal.acme.local`). Dazu gehört auch die interne Dokumentationssuche (`acme docs:search`). |
| `acme-web`      | Die Hauptanwendung. Die meisten Features landen hier.                                                                                                                                                                  |
| `acme-portal`   | Kundenportal. Es greift auf `acme-web` zu.                                                                                                                                                                             |
| `acme-sso`      | Authentifizierungsdienst. Beide Anwendungen hängen davon ab.                                                                                                                                                           |
| `acme-events`   | Event-Consumer.                                                                                                                                                                                                        |

Das ist der interessante Fall, weil die Repositories **nicht unabhängig** sind: In `acme-portal` lässt sich nichts Sinnvolles tun, solange `acme-devtools` nicht installiert ist und `acme-sso` nicht läuft. Daraus ergeben sich zwei Fragen.

<div id="one-blueprint-per-application-or-just-one-for-the-development-cli">
  ### „Ein Blueprint pro Anwendung oder nur einer für die Entwicklungs-CLI?“
</div>

**Beides — sie erfüllen unterschiedliche Aufgaben.** Devin erstellt *einen Snapshot*, der *alle* konfigurierten Repositories enthält, daher ist das keine Entweder-oder-Entscheidung:

* Fügen Sie **alle fünf Repositories** zur Umgebung hinzu, damit sie alle in den Snapshot geklont werden.
* Hinterlegen Sie das **gemeinsame, repository-übergreifende Setup einmalig** im **Organisations-Blueprint**: Sprachruntimes, Docker, lokale Hostnames und Zugangsdaten für die interne Registry.
* Geben Sie jedem Repository sein eigenes **Repository-Blueprint** für seine eigenen Abhängigkeiten und seine eigenen `knowledge`-Einträge (Lint-, Test- und Startbefehle).

Darum sollten Sie nicht alles im `acme-devtools`-Blueprint bündeln: Repository-Blueprints werden ausgeführt, nachdem alle Repositories geklont wurden, aber ihre Schritte laufen **im Verzeichnis des jeweiligen Repositorys**, und ihre `knowledge`-Einträge werden nur geladen, wenn Devin in diesem Repository arbeitet. Wenn `acme-devtools` alles installieren würde, sähe eine Sitzung, die in `acme-portal` arbeitet, keine der Lint- und Testbefehle des Portals, und ein einzelner fehlgeschlagener Schritt in `acme-devtools` würde die anderen vier Repositories zwar gesund erscheinen lassen, sie aber unbrauchbar machen.

<div id="the-organization-blueprint">
  ### Das Organisations-Blueprint
</div>

```yaml Organization-wide setup theme={null}
initialize:
  - name: Install Ruby 3.3
    uses: github.com/ruby/setup-ruby@v1
    with:
      ruby-version: "3.3"

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

  - name: Install Docker and Compose
    run: |
      curl -fsSL https://get.docker.com | sh
      sudo usermod -aG docker "$USER"

  - name: Local hostnames for the development CLI
    run: |
      for host in acme.local portal.acme.local sso.acme.local; do
        grep -q " $host$" /etc/hosts \
          || echo "127.0.0.1 $host" | sudo tee -a /etc/hosts > /dev/null
      done

maintenance:
  - name: Authenticate to the internal registry
    run: |
      bundle config set --global https://gems.acme.internal "$ACME_REGISTRY_TOKEN"
      npm config set //npm.acme.internal/:_authToken "$ACME_REGISTRY_TOKEN"

post-build:
  - name: Verify the stack comes up
    run: |
      acme up --detach
      acme status
      acme down
```

Drei Dinge sind dabei wichtig:

1. **`initialize` versus `maintenance`.** Docker, Runtimes und Hostnames sind eine einmalige Systemeinrichtung und gehören daher in `initialize`. Registry credentials sollten bei jedem regelmäßigen Build erneuert werden und gehören daher in `maintenance`.

   Die `acme`-CLI selbst fehlt hier bewusst. Sie liegt in `acme-devtools`, und Schritte auf Organisationsebene werden **ausgeführt, bevor überhaupt ein Repository geklont wird**. Deshalb wird sie über das Blueprint dieses Repositorys installiert (siehe unten). Diese Installation läuft während des Builds und bleibt im Snapshot erhalten, sodass jedes andere Repository sie verwenden kann.
2. **`post-build` ist der eigentliche Vorteil von Setups mit mehreren Repositorys.** Es wird ausgeführt, nachdem *jedes* Repository geklont und eingerichtet wurde. Deshalb ist das der einzige Ort, an dem Sie prüfen können, ob der gesamte Stack gemeinsam hochfährt. Ein Exit-Code ungleich null lässt den Build fehlschlagen, sodass Sie einen fehlerhaften Stack schon zur Build-Zeit bemerken statt erst mitten in einer Sitzung. Siehe [`post-build`](/de/onboard-devin/environment/blueprint-reference#post-build).
3. **Secrets gehören in die Organisation**, nicht in jedes einzelne Repository. Ein `ACME_REGISTRY_TOKEN` im Tab **Secrets** des Organisations-Blueprints reicht für `bundle install` und `npm install` in jedem Repository.

<Warning>
  **Wichtiger Hinweis zur Reihenfolge:** `initialize` und `maintenance` auf Organisationsebene werden beide **ausgeführt, bevor** Repositories geklont werden (siehe [Build-Reihenfolge](/de/onboard-devin/environment/blueprints#how-builds-work)). Alles, was ausgecheckten Quellcode benötigt — etwa eine CLI, die *in einem* Ihrer Repositories liegt — muss in das Blueprint dieses Repositorys oder in `post-build`, nicht in `maintenance` auf Organisationsebene. Belassen Sie es nur dann auf der Organisationsebene, wenn Sie es aus einem veröffentlichten Artefakt installieren können, etwa aus einem Tarball, einem Package oder einem Container-Image.
</Warning>

<div id="the-repository-blueprints">
  ### Die Repository-Blueprints
</div>

Jedes Repository-Blueprint bleibt kompakt, da alles gemeinsam Genutzte bereits vorhanden ist:

```yaml acme-devtools (repository blueprint) theme={null}
initialize: |
  ./bin/install            # fügt `acme` für den gesamten Snapshot zum PATH hinzu

maintenance: |
  acme docs:index          # aktualisiert den internen Dokumentationsindex bei jedem Build

knowledge:
  - name: cli
    contents: |
      `acme` manages every local service. Common commands:
        acme up <service>     start a service and its dependencies
        acme status           list running services
        acme docs:search <q>  search internal ACME engineering documentation
      Prefer `acme docs:search` over guessing at conventions.
```

```yaml acme-portal (repository blueprint) theme={null}
maintenance: |
  npm install

knowledge:
  - name: lint
    contents: npm run lint
  - name: test
    contents: npm test
  - name: startup
    contents: |
      The portal needs SSO running first:
        acme up sso
        acme up portal
      Then visit https://portal.acme.local
```

`acme-web`, `acme-sso` und `acme-events` folgen demselben Schema: ein `maintenance`-Schritt für ihre jeweiligen Abhängigkeiten und `knowledge`-Einträge für ihre eigenen Lint-, Test- und Startbefehle.

<Tip>
  **`acme-devtools` in der Repository-Liste an erste Stelle setzen**. Repository-Blueprints werden in der in Settings angezeigten Reihenfolge ausgeführt. Daher sollte das Repository, das die gemeinsam genutzte CLI bereitstellt, vor den Repositorys eingerichtet werden, die sie aufrufen.
</Tip>

<Info>
  **Knowledge gilt pro Repository.** Bei fünf konfigurierten Repositorys sieht eine Sitzung in `acme-portal` die Knowledge-Einträge des Portals sowie Knowledge auf Organisations- und Enterprise-Ebene — die Einträge für `acme-web` sieht sie nicht. Deshalb sollte jedes Repository einen eigenen Blueprint haben, auch wenn sein `maintenance`-Abschnitt nur aus einer einzigen Zeile besteht.
</Info>

<Tip>
  Da die `acme`-CLI bereits weiß, wie alles ausgeführt wird, ist der wertvollste Teil dieser Blueprints der Abschnitt **`knowledge`**: Er zeigt Devin, welchen CLI-Befehl es verwenden soll. Verweise dort auf eure interne Dokumentationssuche, falls ihr eine habt.
</Tip>

<div id="if-your-services-live-in-a-monorepo-instead">
  ### Wenn Ihre Services stattdessen in einem Monorepo liegen
</div>

Die Idee ist dieselbe, nur eine Ebene tiefer: Verwenden Sie [Workspaces](/de/onboard-devin/environment/workspaces), um jedem Paket innerhalb eines einzelnen Repositorys ein eigenes Setup und eigenes Knowledge im jeweiligen Geltungsbereich zu geben, anstatt eines Blueprints pro Repository.

***

<div id="stage-3-multiple-organizations-the-enterprise-blueprint">
  ## Stufe 3: mehrere Organisationen — der Enterprise-Blueprint
</div>

ACME hat inzwischen 400 Ingenieure. Platform, Payments und Data haben jeweils ihre eigene Devin-**Organisation**, mit separaten Repositories, separaten Mitgliedern und separaten Snapshots. Ein Sicherheitsteam hat Anforderungen, die für alle gelten:

* Der gesamte Datenverkehr läuft über einen Unternehmens-Proxy mit einer internen Zertifizierungsstelle.
* Alle Pakete kommen aus Artifactory, niemals aus öffentlichen Registries.
* In jeder Umgebung müssen die unternehmenseigenen Tools für Dependency- und Secret-Scans installiert sein.
* Python ist unternehmensweit 3.12 und Node.js 20, ohne Ausnahmen.

Nichts davon gehört in ein Organisations-Blueprint, denn dann müsste es **in jede Organisation kopiert werden**, und es würde in dem Moment voneinander abweichen, in dem ein Team vergisst, es zu aktualisieren. Genau dafür gibt es das **Enterprise-Blueprint**: eine Basisumgebung, die in jedem Build jeder Organisation im gesamten Enterprise zuerst ausgeführt wird.

```yaml Devin's base environment (enterprise blueprint) theme={null}
initialize:
  - name: Corporate certificate authority and proxy
    run: |
      sudo cp "$FILE_ACME_CA_CERT" /usr/local/share/ca-certificates/acme-ca.crt
      sudo update-ca-certificates
      cat <<'EOF' >> ~/.bashrc
      export HTTPS_PROXY=http://proxy.acme.internal:8080
      export NO_PROXY=localhost,127.0.0.1,.acme.internal
      export NODE_EXTRA_CA_CERTS=/usr/local/share/ca-certificates/acme-ca.crt
      export REQUESTS_CA_BUNDLE=/etc/ssl/certs/ca-certificates.crt
      EOF

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

  - name: Security tooling
    run: |
      pip install bandit safety
      curl -sfL https://raw.githubusercontent.com/aquasecurity/trivy/main/contrib/install.sh | sh

maintenance:
  - name: Point every package manager at Artifactory
    run: |
      pip config set global.index-url \
        "https://devin:$ARTIFACTORY_TOKEN@artifactory.acme.internal/api/pypi/pypi/simple/"
      npm config set registry https://artifactory.acme.internal/api/npm/npm/
      npm config set //artifactory.acme.internal/api/npm/npm/:_authToken "$ARTIFACTORY_TOKEN"

knowledge:
  - name: security-policy
    contents: |
      All dependencies must resolve through artifactory.acme.internal.
      Never add a public registry to a lockfile or a CI configuration.
```

`ARTIFACTORY_TOKEN` ist ein **Enterprise-Secret**, das einmal unter **Settings > Devins Basisumgebung > Secrets** definiert wird und in jedem Build sowie in jeder Sitzung in allen Organisationen verfügbar ist. Das Zertifikat liegt als Dateianhang vor und wird dem Build als `$FILE_ACME_CA_CERT` zur Verfügung gestellt.

<div id="what-each-tier-owns-now">
  ### Wofür jetzt jede Ebene zuständig ist
</div>

| Ebene            | Zuständig                                 | ACME-Beispiel                                                                          |
| ---------------- | ----------------------------------------- | -------------------------------------------------------------------------------------- |
| **Enterprise**   | Sicherheits- und Plattformadministratoren | Zertifizierungsstelle, Proxy, Artifactory, Python 3.12, Scanner, ein gemeinsames Token |
| **Organization** | Die Administratoren jedes Teams           | Payments: Docker, die `acme`-CLI und die Hostnames des Teams. Data: Spark und JDK 17.  |
| **Repository**   | Wer auch immer das Repository betreut     | `bundle install`, `npm install` sowie Knowledge zu Linting, Tests und Startvorgang     |

Das Organisations-Blueprint von Payments aus Phase 2 funktioniert **unverändert** weiter. Es muss lediglich kein Python mehr installieren und keine Registries mehr konfigurieren, da die Enterprise-Ebene das bereits übernommen hat. Das Organisations-Blueprint von Data installiert Spark und ein JDK, mit denen Payments nie in Berührung kommt. Repository-Blueprints bleiben unverändert.

<div id="operating-it">
  ### Im Betrieb
</div>

* **Das Upgrade von Python 3.12 auf 3.13** erfordert nur eine einzeilige Änderung plus einen [unternehmensweiten Rebuild](/de/enterprise/environment-management/overview#enterprise-wide-rebuilds), der an jede Organisation weitergegeben wird.
* **Wenn ein Team andere Zugangsdaten benötigt** — etwa weil die Data-Organisation ihre eigene Artifactory-Realm hat — definiert dieses Team ein Organisations-Secret mit demselben Namen, das das Enterprise-Secret **überschreibt**.
* **Für eine schrittweise Einführung** über mehrere Organisationen hinweg siehe [Migration Ihres Enterprise-Kontos](/de/enterprise/environment-management/rollout).

***

<div id="deciding-where-something-goes">
  ## Entscheiden, wohin etwas gehört
</div>

Gehen Sie die Liste der Reihe nach durch. Das erste „Ja“ ist die Antwort:

<Steps>
  <Step title="Braucht jede Organisation im Unternehmen das?">
    → **Enterprise-Blueprint.** Zertifikate, Proxys, interne Registries, vorgeschriebene Runtimes, Security-Tools und unternehmensweite Secrets.
  </Step>

  <Step title="Brauchen zwei oder mehr Repositories in dieser Organisation das?">
    → **Organisations-Blueprint.** Docker, gemeinsam genutzte Entwicklungs-CLIs, lokale Hostnames, repository-übergreifende Service-Orchestrierung und Registry-Zugangsdaten. Prüfen Sie den zusammengestellten Stack in `post-build`.
  </Step>

  <Step title="Braucht nur dieses Repository das?">
    → **Repository-Blueprint.** Abhängigkeitsinstallationen, Migrationen und die `knowledge`-Einträge für die Lint-, Test- und Startbefehle.
  </Step>

  <Step title="Ist es eine Tatsache und kein auszuführender Befehl?">
    → **`knowledge`**, auf der jeweils passenden Ebene. Es wird nie ausgeführt; es wird in Devins Kontext geladen.
  </Step>
</Steps>

Häufige Fehler, die dadurch vermieden werden:

* **Alles in das Blueprint eines einzelnen Repositorys packen.** Die anderen Repositories erhalten keine `knowledge`-Einträge, und ein einzelner fehlerhafter Schritt lässt das gesamte Setup fehlerhaft wirken.
* **Gemeinsam genutzte Tools pro Repository duplizieren.** Wenn zwei Repositories unterschiedliche Versionen desselben globalen Tools installieren, setzt sich die zuletzt ausgeführte durch. Platzieren Sie das Tool stattdessen im Organisations-Blueprint.
* **Repository-übergreifende Überprüfung überspringen.** Wenn Ihre Repositories nur gemeinsam funktionieren, ist `post-build` der einzige Ort, der das belegt — bevor eine Sitzung beginnt, statt erst währenddessen.

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

* [Deklarative Konfiguration](/de/onboard-devin/environment/blueprints) — Build-Reihenfolge, Snapshots und Fehlerbehebung
* [Blueprint-Referenz](/de/onboard-devin/environment/blueprint-reference) — alle Felder, einschließlich `post-build` und `clone`
* [Vorlagenbibliothek](/de/onboard-devin/environment/templates) — Blueprints zum Kopieren und Einfügen nach Sprache und Registry
* [Workspaces und Monorepos](/de/onboard-devin/environment/workspaces) — das Monorepo-Pendant zu Stufe 2
* [Überblick über Enterprise-Umgebungen](/de/enterprise/environment-management/overview) — Stufe 3 in allen Details