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

# Blueprint-Referenz

> Vollständige Feldreferenz für Blueprints: Abschnitte, Schritttypen, GitHub Actions, Umgebungsvariablen, Secrets und Dateianhänge.

<Info>
  Dies ist die vollständige Feldreferenz für Blueprints. Eine Einführung in Blueprints und ihre Rolle in Devins Umgebung finden Sie unter [Deklarative
  Umgebungskonfiguration](/de/onboard-devin/environment/blueprints).
</Info>

Ein Blueprint definiert, wie Devins Umgebung konfiguriert wird: welche Tools installiert werden, wie Abhängigkeiten aktuell gehalten werden und welche Befehle Devin kennen soll.

<div id="overview">
  ## Überblick
</div>

Ein Blueprint besteht aus drei grundlegenden Abschnitten auf oberster Ebene sowie aus einem Abschnitt `post-build` für Blueprints auf Org- und Enterprise-Ebene und optional aus einem Abschnitt `clone` für Blueprints auf Repo-Ebene:

```yaml theme={null}
initialize: ...   # Install tools and runtimes
maintenance: ...  # Install project dependencies
knowledge: ...    # Reference info for Devin (never executed)
post-build: ...   # (Nur für Org/Enterprise) Befehle, die nach dem gesamten Setup ausgeführt werden
clone: ...        # (Repo-level only) Override git-clone defaults
```

| Abschnitt     | Zweck                                                                                                  | Ausgeführt?                                                                                              |
| ------------- | ------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------- |
| `initialize`  | System-Tools, Laufzeitumgebungen für Programmiersprachen und globale CLIs installieren                 | Bei vollständigen Builds und für von Grund auf neu aufgebaute Workspaces                                 |
| `maintenance` | Projektabhängigkeiten installieren und aktualisieren                                                   | Ja, bei Builds. Dem Agenten zu Sitzungsbeginn als Kontext angezeigt (wird nicht automatisch ausgeführt). |
| `knowledge`   | Devin Anweisungen zum Linten, Testen und Bauen sowie weitere projektspezifische Informationen geben    | Nein, nur als Referenz                                                                                   |
| `post-build`  | Befehle, die ausgeführt werden, nachdem alle Repo geklont und eingerichtet wurden (nur org/Enterprise) | Ja, bei Builds — ein Exit-Code ungleich null lässt den Build fehlschlagen                                |
| `clone`       | Überschreibt, wie das Repository in den Snapshot geklont wird (nur auf Repo-Ebene)                     | Wird während des Clone-Schritts des Builds angewendet                                                    |

Alle Abschnitte sind optional. Sie können jede beliebige Kombination verwenden.

`initialize` wird bei vollständigen Builds und für Workspaces ausgeführt, die von Grund auf neu aufgebaut werden. Die Ergebnisse werden im Snapshot gespeichert. In einem [differenziellen Build](/de/onboard-devin/environment/differential-builds) überspringen vererbte Workspaces `initialize`, ziehen den neuesten Code und führen nur `maintenance` aus. Schreiben Sie `maintenance` so, dass es in sich abgeschlossen ist und unabhängig auf dem vorhandenen Snapshot ausgeführt werden kann, ohne dass `initialize` unmittelbar zuvor ausgeführt werden muss oder auf Umgebungsvariablen angewiesen ist, die `initialize` zuvor in `$ENVRC` geschrieben hat. Zu Beginn jeder Sitzung werden `maintenance`-Befehle **nicht automatisch ausgeführt** — stattdessen werden sie dem Agenten als Kontext angezeigt, damit er weiß, welche Befehle für Abhängigkeiten bei Bedarf ausgeführt werden müssen (z. B. nach dem Abrufen des neuesten Codes). Die Befehle sollten weiterhin schnell und inkrementell sein. Builds werden automatisch ausgeführt, wenn sich Ihr Blueprint ändert, und außerdem regelmäßig (ca. alle 24 Stunden).

<div id="initialize">
  ## initialize
</div>

Verwende `initialize`, um Tools und Laufzeitumgebungen zu installieren, die nicht vom konkreten Zustand deines Codes abhängen: Laufzeitumgebungen für Programmiersprachen, Systempakete, globale CLIs.

<div id="simple-form">
  ### Einfache Form
</div>

Für einfache Shell-Befehle verwenden Sie einen Blockskalar:

```yaml theme={null}
initialize: |
  curl -LsSf https://astral.sh/uv/install.sh | sh
  apt-get update && apt-get install -y build-essential
  npm install -g pnpm
```

<div id="structured-form">
  ### Strukturierte Form
</div>

Verwenden Sie für benannte Schritte, Umgebungsvariablen oder GitHub Actions eine Liste:

```yaml theme={null}
initialize:
  - name: "Install Python 3.12"
    uses: github.com/actions/setup-python@v5
    with:
      python-version: "3.12"

  - name: "Install system packages"
    run: |
      apt-get update
      apt-get install -y libpq-dev

  - name: "Install global tools"
    run: pip install uv
    env:
      PIP_BREAK_SYSTEM_PACKAGES: "1"
```

Beide Formen können kombiniert werden. Die einfache Form entspricht einem einzelnen Schritt mit `run`.

<div id="when-to-use-initialize-vs-maintenance">
  ### Wann `initialize` statt `maintenance` verwenden
</div>

| In `initialize`                                           | In `maintenance` einfügen        |
| --------------------------------------------------------- | -------------------------------- |
| Installation der Laufzeitumgebung für Programmiersprachen | `npm install` / `pip install`    |
| Systempakete (`apt-get`)                                  | `bundle install`                 |
| Globale CLI-Tools                                         | `go mod download`                |
| Einmalige Konfiguration                                   | Updates des Abhängigkeits-Caches |
| GitHub Actions (`setup-python`, etc.)                     | Repo-spezifische Setup-Skripte   |

Beide Abschnitte werden bei vollständigen Builds ausgeführt. Bei differenziellen Builds überspringen vererbte Workspaces `initialize` und führen nach dem Abrufen des neuesten Codes nur `maintenance` aus. Tools und Laufzeitumgebungen für Programmiersprachen gehören in `initialize`; Abhängigkeitsbefehle, die sich an den Lock-Dateien Ihres Codes orientieren, gehören in `maintenance`.

<div id="maintenance">
  ## maintenance
</div>

Verwenden Sie `maintenance` für die Installation von Abhängigkeiten und andere Befehle, die nach dem Klonen Ihres Codes ausgeführt werden sollen. Diese Befehle werden während Builds ausgeführt und dem Agenten zu Beginn der Sitzung angezeigt, damit er sie erneut ausführen kann, wenn sich Abhängigkeiten geändert haben. Hierhin gehören `npm install`, `pip install`, `uv sync` und ähnliche Befehle.

```yaml theme={null}
maintenance: |
  npm install
  pip install -r requirements.txt
```

Oder in strukturierter Form:

```yaml theme={null}
maintenance:
  - name: "Install npm dependencies"
    run: npm install

  - name: "Install Python dependencies"
    run: uv sync
    env:
      UV_CACHE_DIR: /tmp/uv-cache
```

<Info>Für Blueprints auf Repo-Ebene werden `maintenance`-Befehle im Root-Verzeichnis des Repos ausgeführt. Für Blueprints auf Org-Ebene werden sie im Home-Verzeichnis (`~`) ausgeführt.</Info>

<div id="knowledge">
  ## knowledge
</div>

Der Abschnitt `knowledge` wird **nicht ausgeführt**. Er enthält Referenzinformationen, die Devin bei der Arbeit an Ihrem Projekt verwendet. Hier geben Sie Devin die richtigen Befehle für Linting, Tests, Builds und andere projektspezifische Workflows an.

```yaml theme={null}
knowledge:
  - name: lint
    contents: |
      Run linting with:
      npm run lint

      For auto-fix:
      npm run lint -- --fix

  - name: test
    contents: |
      Run the full test suite:
      npm test

      Run a single test file:
      npm test -- path/to/test.ts

  - name: build
    contents: |
      npm run build

      Build output goes to dist/
```

Jeder Knowledge-Eintrag hat:

| Feld       | Typ    | Beschreibung                                                            |
| ---------- | ------ | ----------------------------------------------------------------------- |
| `name`     | string | Bezeichner für diesen Knowledge-Eintrag (z. B. `lint`, `test`, `build`) |
| `contents` | string | Freitext mit Befehlen, Anweisungen oder Hinweisen                       |

Das Feld `name` ist eine Bezeichnung. Üblicherweise sind `lint`, `test` und `build` die Standardnamen. Bei der Überprüfung seiner Arbeit greift Devin auf diese zurück. Sie können beliebige zusätzliche Knowledge-Einträge mit benutzerdefinierten Namen hinzufügen:

```yaml theme={null}
knowledge:
  - name: lint
    contents: ...
  - name: test
    contents: ...
  - name: build
    contents: ...
  - name: deploy
    contents: |
      Deploy to staging:
      npm run deploy:staging
  - name: database
    contents: |
      Run migrations:
      npm run db:migrate

      Seed test data:
      npm run db:seed
```

<div id="post-build">
  ## post-build
</div>

Der Abschnitt `post-build` ist **nur in Blueprints auf Organisations- und Enterprise-Ebene** verfügbar (in Blueprints auf Repo-Ebene wird er nicht unterstützt). Seine Schritte werden während des Builds **ausgeführt, nachdem alle Repositorys geklont wurden und ihre Schritte `initialize` und `maintenance` abgeschlossen sind**, aber bevor die Integritätsprüfung durchgeführt und das Snapshot-Image erstellt wird. Damit ist dies der richtige Ort für Repository-übergreifende Validierungen und Integritätsprüfungen, die die vollständig aufgebaute Umgebung benötigen.

Da er erst spät im Build ausgeführt wird, wenn die gesamte Umgebung bereitsteht, kann ein `post-build`-Schritt jedes geklonte Repo und jedes Tool sehen, das von den Enterprise-, Org- und Repo-Blueprints installiert wurde.

```yaml theme={null}
post-build: |
  # Überprüfe, ob die zusammengestellte Umgebung fehlerfrei ist
  node --version
  python --version
  test -d ~/repos/my-service
```

Oder in strukturierter Form:

```yaml theme={null}
post-build:
  - name: "Verify toolchain"
    run: |
      node --version
      uv --version

  - name: "Smoke-test the workspace"
    run: ~/repos/my-service/scripts/healthcheck.sh
```

<Warning>
  `post-build`-Schritte **lassen den Build bei einem Exit-Code ungleich null fehlschlagen**. Wenn ein `post-build`-Schritt mit einem Exit-Code ungleich null beendet wird, wird der Build als fehlgeschlagen markiert und es wird kein Snapshot-Image erzeugt. Verwenden Sie dies, um Snapshots an Integritätsprüfungen zu knüpfen — stellen Sie aber sicher, dass die Befehle zuverlässig sind, damit ein instabiler Check Ihre Builds nicht blockiert.
</Warning>

<Info>
  `post-build`-Schritte verwenden dieselben [Schritttypen](#step-types) wie `initialize` und `maintenance` (Shell-`run`-Befehle und GitHub-Actions-`uses`) und werden aus dem Home-Verzeichnis (`~`) ausgeführt.
</Info>

<div id="clone">
  ## clone
</div>

Für **Blueprints auf Repo-Ebene** überschreibt der optionale Abschnitt `clone` die Standardwerte, die Devin verwendet, wenn das Repository in den Snapshot geklont wird. Jedes Feld ist optional und greift andernfalls auf einen sinnvollen Standard zurück, der das aktuelle Verhalten beibehält.

```yaml theme={null}
clone:
  path: my-project        # Klonziel unter ~/repos/ (Standard: Kurzname des Repos)
  ref: develop            # Branch oder Tag zum Auschecken (Standard: Standard-Branch des Repos)
  depth: 1                # 0 = vollständige Historie, N = --depth N (Standard: 0)
  tags: false             # false übergibt --no-tags (Standard: true)
  submodules: recursive   # true / false / "recursive" (Standard: true)
  lfs: false              # false setzt GIT_LFS_SKIP_SMUDGE=1 beim Klonen (Standard: true)
```

| Feld         | Typ                   | Standard                 | Beschreibung                                                                                                                                |
| ------------ | --------------------- | ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------- |
| `path`       | string                | Repo-Kurzname            | Überschreibt das Zielverzeichnis für den Klonvorgang unter `~/repos/`. Muss innerhalb desselben Snapshots repo-übergreifend eindeutig sein. |
| `ref`        | string                | Standard-Branch des Repo | Branch oder Tag, der nach dem Klonen ausgecheckt wird. Commit-SHAs werden hier nicht unterstützt.                                           |
| `depth`      | int                   | `0`                      | Klontiefe. `0` klont den vollständigen Verlauf; jeder positive Wert übergibt `--depth N` für einen Shallow Clone.                           |
| `tags`       | bool                  | `true`                   | Wenn `false`, wird `--no-tags` übergeben, um das Abrufen von Git-Tags zu überspringen.                                                      |
| `submodules` | bool or `"recursive"` | `true`                   | `true` oder `"recursive"` übergibt `--recurse-submodules`. `false` überspringt Submodule vollständig.                                       |
| `lfs`        | bool                  | `true`                   | Wenn `false`, wird `GIT_LFS_SKIP_SMUDGE=1` gesetzt, um das Herunterladen von Git-LFS-Objekten beim Klonen zu überspringen.                  |

<Info>
  `clone` gilt nur für **auf Repo-Ebene** Blueprints — es steuert, wie das jeweilige Repo in den Snapshot geklont wird. In Blueprints auf Org-Ebene oder enterprise-level hat es keine Wirkung.
</Info>

<div id="step-types">
  ## Schritttypen
</div>

Jeder Schritt in `initialize`, `maintenance` oder `post-build` gehört zu einem von zwei Typen: Shell-Befehle (`run`) oder GitHub Actions (`uses`).

<div id="shell-commands-run">
  ### Shell-Befehle (`run`)
</div>

Führen Sie beliebige Shell-Befehle in Bash aus:

```yaml theme={null}
- name: "Install dependencies"
  run: |
    npm install
    pip install -r requirements.txt
```

| Feld   | Typ               | Beschreibung                                      |
| ------ | ----------------- | ------------------------------------------------- |
| `name` | string (optional) | Menschenlesbare Bezeichnung für den Schritt       |
| `run`  | string            | Auszuführende Shell-Befehle                       |
| `env`  | map (optional)    | Zusätzliche Umgebungsvariablen für diesen Schritt |

**Ausführungsdetails:**

* Befehle werden in bash ausgeführt. Wenn in einem mehrzeiligen Skript ein Befehl fehlschlägt, wird der gesamte Schritt sofort abgebrochen.
* Blueprints auf Org-Ebene werden im Home-Verzeichnis (`~`) ausgeführt.
* Blueprints auf Repo-Ebene werden im Root-Verzeichnis des geklonten Repositorys ausgeführt.
* Jeder Schritt hat ein Timeout von 1 Stunde.
* Secrets sind automatisch als Umgebungsvariablen verfügbar.

<div id="github-actions-uses">
  ### GitHub Actions (`uses`)
</div>

Führen Sie Node.js-basierte GitHub Actions direkt in Ihrem Blueprint aus:

```yaml theme={null}
- name: "Install Python"
  uses: github.com/actions/setup-python@v5
  with:
    python-version: "3.12"
```

| Feld   | Typ               | Beschreibung                                      |
| ------ | ----------------- | ------------------------------------------------- |
| `name` | string (optional) | Menschenlesbare Bezeichnung für den Schritt       |
| `uses` | string            | Referenz auf eine GitHub Action                   |
| `with` | map (optional)    | Eingabeparameter für die Action                   |
| `env`  | map (optional)    | Zusätzliche Umgebungsvariablen für diesen Schritt |

**Format der Action-Referenz:**

```
github.com/<owner>/<repo>@<ref>
github.com/<owner>/<repo>/<subpath>@<ref>
```

Das Präfix `github.com/` und das Suffix `@<ref>` sind beide erforderlich. Die Referenz ist in der Regel ein Versions-Tag wie `v5`.

**Häufig verwendete Actions:**

| Action                                      | Zweck                 | Beispiel für `with`                             |
| ------------------------------------------- | --------------------- | ----------------------------------------------- |
| `github.com/actions/setup-python@v5`        | Python installieren   | `python-version: "3.12"`                        |
| `github.com/actions/setup-node@v4`          | Node.js installieren  | `node-version: "20"`                            |
| `github.com/actions/setup-go@v5`            | Go installieren       | `go-version: "1.22"`                            |
| `github.com/actions/setup-java@v4`          | Java/JDK installieren | `java-version: "21"`, `distribution: "temurin"` |
| `github.com/gradle/actions/setup-gradle@v4` | Gradle installieren   | (keine)                                         |
| `github.com/ruby/setup-ruby@v1`             | Ruby installieren     | `ruby-version: "3.3"`                           |

<Warning>Unterstützt werden nur **Node.js-basierte** GitHub Actions. Composite Actions und Docker-basierte Actions werden nicht unterstützt.</Warning>

**So funktionieren `with`-Werte:**

Werte, die über `with` übergeben werden, werden der Action als Eingaben übergeben und folgen dabei denselben Konventionen wie in GitHub-Actions-Workflows. Alle Werte werden in Zeichenfolgen umgewandelt.

```yaml theme={null}
with:
  python-version: "3.12"
  check-latest: true
  cache: "pip"
```

**Wie Aktionen Änderungen weiterreichen:**

Aktionen können die Umgebung für nachfolgende Schritte ändern. Zum Beispiel fügt `setup-python` die Python-Binärdatei zu `PATH` hinzu, sodass sie in allen späteren Schritten und in `maintenance` verfügbar bleibt.

<div id="run-vs-uses-which-to-use">
  ### `run` vs. `uses`: wann Sie was verwenden sollten
</div>

| `run` verwenden, wenn...                         | `uses` verwenden, wenn...                                                                     |
| ------------------------------------------------ | --------------------------------------------------------------------------------------------- |
| Systempakete installiert werden (`apt-get`)      | Laufzeitumgebungen für Programmiersprachen eingerichtet werden (Python, Node, Go, Java, Ruby) |
| projektspezifische Skripte ausgeführt werden     | es eine offizielle GitHub Action für Ihre Anforderungen gibt                                  |
| Dateien oder die Umgebung konfiguriert werden    | Sie automatische Versionsverwaltung und Caching nutzen möchten                                |
| der Befehl einfach und in sich abgeschlossen ist | Sie dieselbe Action in einem GitHub-Actions-Workflow verwenden würden                         |

In der Praxis verwenden die meisten Konfigurationen `uses` für Laufzeitumgebungen von Programmiersprachen und `run` für alles andere.

<div id="environment-variables-and-secrets">
  ## Umgebungsvariablen und Secrets
</div>

<div id="step-level-environment-variables">
  ### Umgebungsvariablen pro Schritt
</div>

Jeder Schritt kann mit dem Feld `env` zusätzliche Umgebungsvariablen definieren:

```yaml theme={null}
- run: pip install -r requirements.txt
  env:
    PIP_INDEX_URL: "https://pypi.example.com/simple/"
    PIP_BREAK_SYSTEM_PACKAGES: "1"
```

Diese gelten nur für den jeweiligen Schritt und bleiben in nachfolgenden Schritten nicht erhalten.

<div id="cross-step-environment-variables-envrc">
  ### Schrittübergreifende Umgebungsvariablen (`$ENVRC`)
</div>

Um Umgebungsvariablen über mehrere Schritte hinweg weiterzugeben, schreiben Sie sie in die Datei `$ENVRC`:

```yaml theme={null}
- name: "Set shared variables"
  run: |
    echo "DATABASE_URL=postgresql://localhost:5432/myapp" >> $ENVRC
    echo "APP_ENV=development" >> $ENVRC
```

In `$ENVRC` geschriebene Variablen werden automatisch exportiert und stehen in allen
nachfolgenden Schritten sowie in der Devin-Sitzung zur Verfügung, die durch den aktuellen Build erzeugt wird. Das funktioniert
ähnlich wie `$GITHUB_ENV` in GitHub Actions.

Dies gilt auch für `PATH`. Wenn Sie ein Tool in einem nicht standardmäßigen Verzeichnis
installieren (alles außerhalb von `/usr/bin` oder `/usr/local/bin`), fügen Sie den Pfad zu `$ENVRC` hinzu, damit
nachfolgende Schritte und Blueprints auf Repo-Ebene die Binärdatei finden können:

```yaml theme={null}
- name: "Install latest direnv"
  run: |
    curl -sfL https://direnv.net/install.sh | bash
    echo 'export PATH="$HOME/.local/bin:$PATH"' >> $ENVRC
```

Ein einfaches `export PATH=...` innerhalb eines `run:`-Blocks gilt nur für die Shell dieses Schritts.
Jeder Schritt startet einen neuen Shell-Prozess, sodass `PATH`-Änderungen, die nicht in
`$ENVRC` geschrieben werden, verloren gehen.

<Info>
  `uses:`-Actions (z. B. `actions/setup-node`) übernehmen ihre `PATH`-
  Ergänzungen automatisch in `$ENVRC` — Sie müssen dies nur bei `run:`-Schritten manuell tun.
</Info>

`$ENVRC` wird zu Beginn jedes Builds zurückgesetzt, einschließlich differenzieller Builds.
Werte, die während eines Builds geschrieben werden, sind im nächsten Build nicht verfügbar. Insbesondere führt ein
vererbter Workspace nur `maintenance` aus, sodass er sich nicht auf
`PATH` oder andere Variablen verlassen kann, die `initialize` im übergeordneten
Build in `$ENVRC` geschrieben hat. Konfigurieren Sie alle von
`maintenance` benötigten Umgebungen innerhalb von
`maintenance` selbst.

<script src="/anchor-scroll-fix.js" />

<div id="secrets">
  ### Secrets
</div>

In der Devin-Benutzeroberfläche konfigurierte Secrets (über den **Secrets**-Tab in jedem Blueprint-Editor) werden automatisch als Umgebungsvariablen eingefügt. Sie müssen sie nicht in Ihrem Blueprint deklarieren. Verweisen Sie einfach per Namen darauf (z. B. `$MY_SECRET`).

Secrets werden vor jedem Schritt während Builds eingefügt **und** zu Beginn jeder Sitzung erneut eingefügt. Aus dem Snapshot-Image selbst werden sie entfernt, sodass Zugangsdaten niemals in gespeicherte Maschinenabbilder eingebettet sind.

* **Organisations-Secrets**: Als Umgebungsvariablen in jedem Schritt aller Blueprints in der org verfügbar. Konfigurieren Sie diese im **Secrets**-Tab des Editors für das organisationsweite Blueprint.
* **Enterprise-Secrets**: Werden mit org-Secrets zusammengeführt (bei Namenskonflikten haben org-Secrets Vorrang). In allen orgs im Enterprise verfügbar.
* **Repository-Secrets**: Werden in eine Repo-spezifische Datei unter `/run/repo_secrets/{owner/repo}/.env.secrets` geschrieben. Während Builds werden Repo-Secrets automatisch geladen, bevor die Blueprint-Schritte dieses Repos ausgeführt werden. Während Sitzungen lädt Devin sie, wenn im Repo gearbeitet wird. Konfigurieren Sie diese im **Secrets**-Tab des Blueprint-Editors des Repositorys.

<Info>
  **Nur-Build-Secrets**: Secrets, die als "build only" markiert sind, sind während Snapshot-Builds verfügbar, werden aber entfernt, bevor der Snapshot gespeichert wird. Verwenden Sie diese für Zugangsdaten, die nur während des Builds benötigt werden (z. B. zum Herunterladen privater Artefakte während `initialize`).
</Info>

<Warning>
  `maintenance` wird während Builds ausgeführt. Zu Beginn einer Sitzung werden `maintenance`-Befehle dem Agent angezeigt (nicht automatisch ausgeführt), sodass der Agent sie bei Bedarf erneut ausführen kann. Wenn ein `maintenance`-Schritt Secrets in Konfigurationsdateien schreibt (z. B. `~/.m2/settings.xml`, `~/.npmrc`), werden diese Dateien in den Snapshot eingebettet. Platzieren Sie Schritte, die Zugangsdaten schreiben, in `maintenance` (nicht in `initialize`), damit sie während periodischer Builds aktualisiert werden. Beachten Sie aber, dass die geschriebenen Dateien im Image erhalten bleiben. Für maximale Sicherheit sollten Sie Umgebungsvariablen oder `$ENVRC` verwenden, anstatt Zugangsdaten auf den Datenträger zu schreiben.
</Warning>

<div id="file-attachments">
  ### Dateianhänge
</div>

Sie können Dateien (wie `.npmrc`, `settings.xml` oder Konfigurationsdateien) über den Blueprint-Editor hochladen. Hochgeladene Dateien werden unter `~/.files/` abgelegt, und es wird eine Umgebungsvariable gesetzt, die auf den Pfad der jeweiligen Datei verweist:

```
$FILE_SETTINGS_XML    -> /home/ubuntu/.files/settings.xml
$FILE_NPMRC           -> /home/ubuntu/.files/.npmrc
```

Der Variablenname wird vom Dateinamen abgeleitet: in Großbuchstaben, wobei nicht alphanumerische Zeichen durch Unterstriche ersetzt und mit dem Präfix `FILE_` versehen werden.

Verwenden Sie Dateianhänge in Ihren Blueprint-Schritten:

```yaml theme={null}
maintenance:
  - name: "Configure Maven"
    run: |
      mkdir -p ~/.m2
      cp "$FILE_SETTINGS_XML" ~/.m2/settings.xml
```

<div id="git-backed-blueprints">
  ## Git-gestützte Blueprints
</div>

Sie können Blueprints als `.devin/blueprint.yaml`-Dateien direkt in Ihrem Repository speichern und anschließend über die API oder die UI synchronisieren. Weitere Informationen und Anweisungen zum Setup finden Sie unter [Git-gestützte Blueprints](/de/onboard-devin/environment/git-backed-blueprints).

<div id="complete-example">
  ## Vollständiges Beispiel
</div>

<Info>
  Informationen dazu, wie Blueprints über verschiedene Ebenen hinweg zusammenwirken (enterprise → org → repo), zu Build-Status, Repository-Zuständen und dazu, was einen erneuten Build auslöst, finden Sie unter [Builds und Sitzungen](/de/onboard-devin/environment/blueprints#builds-and-sessions) auf der Seite zur deklarativen Konfiguration.
</Info>

<div id="org-wide-blueprint">
  ### Organisationsweites Blueprint
</div>

Gemeinsam genutzte Tools, die jedes Repo in der Org benötigt. Dieses Blueprint wird zuerst ausgeführt (nach einem etwaigen Enterprise-Blueprint), und zwar im Home-Verzeichnis.

```yaml theme={null}
initialize:
  - name: "Install Node.js 20"
    uses: github.com/actions/setup-node@v4
    with:
      node-version: "20"

  - name: "Install Python 3.12 and uv"
    run: |
      curl -LsSf https://astral.sh/uv/install.sh | sh

  - name: "Install shared tools"
    run: |
      npm install -g pnpm turbo
      apt-get update && apt-get install -y jq ripgrep

  - name: "Configure private registry"
    run: |
      echo "//npm.corp.example.com/:_authToken=$NPM_REGISTRY_TOKEN" >> ~/.npmrc
```

<div id="repo-level-blueprint">
  ### Blueprint auf Repo-Ebene
</div>

Projektspezifische Einrichtung für ein Node.js- und Python-Monorepo. Sie wird nach dem organisationsweiten Blueprint im Repository-Verzeichnis ausgeführt.

```yaml theme={null}
initialize:
  - name: "Install Playwright browsers"
    run: npx playwright install --with-deps chromium

  - name: "Set up project environment variables"
    run: |
      echo "DATABASE_URL=postgresql://localhost:5432/myapp_dev" >> $ENVRC
      echo "REDIS_URL=redis://localhost:6379" >> $ENVRC
      echo "APP_ENV=development" >> $ENVRC

maintenance:
  - name: "Install frontend dependencies"
    run: |
      cd frontend
      pnpm install

  - name: "Install backend dependencies"
    run: |
      cd backend
      uv sync

  - name: "Run database migrations"
    run: |
      cd backend
      uv run alembic upgrade head
    env:
      DATABASE_URL: "postgresql://localhost:5432/myapp_dev"

knowledge:
  - name: lint
    contents: |
      Frontend:
      cd frontend && pnpm lint

      Backend:
      cd backend && uv run ruff check .

      Auto-fix:
      cd frontend && pnpm lint --fix
      cd backend && uv run ruff check --fix .

  - name: test
    contents: |
      Frontend unit tests:
      cd frontend && pnpm test

      Backend unit tests:
      cd backend && uv run pytest

      E2E tests (requires dev server running):
      cd frontend && pnpm test:e2e

  - name: build
    contents: |
      Frontend:
      cd frontend && pnpm build

      Backend:
      cd backend && uv run python -m build

  - name: dev-server
    contents: |
      Start the full development stack:
      cd backend && uv run uvicorn main:app --reload &
      cd frontend && pnpm dev

      Frontend: http://localhost:3000
      Backend API: http://localhost:8000
      API docs: http://localhost:8000/docs

  - name: database
    contents: |
      Run migrations:
      cd backend && uv run alembic upgrade head

      Create a new migration:
      cd backend && uv run alembic revision --autogenerate -m "description"

      Reset the database:
      cd backend && uv run alembic downgrade base && uv run alembic upgrade head
```