> ## 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.
# Differenzielle Builds
> Beschleunigen Sie Snapshot-Builds, indem Sie nur Workspaces neu erstellen, deren Blueprints geändert wurden. Unveränderte Workspaces werden aus dem vorherigen erfolgreichen Build übernommen.
## Übersicht
Standardmäßig ist jeder Snapshot-Build ein **vollständiger Build** — er startet mit einem sauberen Basis-Image, klont alle Repositorys und führt jedes Blueprint von Grund auf neu aus. Das gewährleistet eine vollständig reproduzierbare Umgebung, kann aber langsam sein, wenn Sie nur eines von vielen Blueprints geändert haben.
**Differenzielle Builds** optimieren diesen Prozess, indem sie den Snapshot des vorherigen erfolgreichen Builds als Ausgangspunkt wiederverwenden. Nur Workspaces, deren Blueprints tatsächlich geändert wurden, werden neu gebaut; unveränderte Workspaces werden unverändert aus dem übergeordneten Build übernommen. Dadurch lassen sich die Build-Zeiten deutlich verkürzen, insbesondere für Organisationen mit vielen Repositorys.
## Aktivieren von differenziellen Builds
Gehen Sie zu **Settings > Environment > Erweitert**.
Aktivieren Sie den Schalter **differenzielle Builds**. Die Beschreibung lautet: *„Schnellere Builds durch Wiederverwendung unveränderter Workspaces.“*
Speichern Sie eine Blueprint-Änderung oder klicken Sie auf **Build snapshot**. Beim nächsten Build wird ein differenzieller Build verwendet, sofern ein gültiger übergeordneter Build vorhanden ist.
Der erste Build nach dem Aktivieren von differenziellen Builds ist immer ein **vollständiger Build** — das System benötigt einen erfolgreichen Ausgangsbasis-Snapshot als Vergleichsgrundlage. Nachfolgende Builds sind differenziell, solange ein gültiger übergeordneter Build vorhanden ist.
## So funktioniert es
Wenn bei aktivierten differenziellen Builds ein Build ausgelöst wird, folgt das System diesem Ablauf:
### 1. Einen übergeordneten Build finden
Das System sucht nach dem zuletzt erfolgreichen Build (Status `success` oder `partial`), um ihn als übergeordneten Build zu verwenden. Wenn kein geeigneter übergeordneter Build vorhanden ist, fällt der Build automatisch auf einen vollständigen Build zurück.
### 2. Blueprints vergleichen
Die Konfiguration jedes Workspaces wird mit dem übergeordneten Build verglichen. Das System berechnet für jeden Workspace einen Hashwert seiner Eingaben — einschließlich der Blueprint-Inhalte, angehängten Dateien, Secrets und der Reihenfolge der Repositories — und prüft, was sich geändert hat.
### 3. Workspace-Aktionen zuweisen
Auf Grundlage des Vergleichs erhält jeder Workspace eine von drei Aktionen:
| Aktion | Was passiert | Wann sie zum Einsatz kommt |
| ----------- | ---------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------- |
| **Rebuild** | Repo klonen und alle Blueprint-Schritte (`initialize` + `maintenance`) von Grund auf ausführen | Der Blueprint wurde seit dem übergeordneten Build geändert |
| **Inherit** | Den neuesten Code abrufen und nur `maintenance`-Schritte ausführen | Der Blueprint ist unverändert — das Setup des übergeordneten Builds wiederverwenden |
| **Remove** | Den Workspace aus dem Snapshot löschen | Der Workspace wurde aus der Konfiguration entfernt |
Bei vererbten Workspaces wird `initialize` nicht erneut ausgeführt. Schreiben Sie `maintenance`
so, dass es in sich geschlossen ist und nach dem Abrufen des neuesten Codes
eigenständig ausgeführt werden kann. Es kann Tools und Runtimes verwenden, die bereits im übergeordneten Snapshot installiert sind,
darf aber nicht voraussetzen, dass `initialize` unmittelbar davor ausgeführt wurde, oder sich auf
Umgebungsvariablen verlassen, die `initialize` zuvor in `$ENVRC` geschrieben hat.
### 4. Build ausführen
Der Build startet vom Snapshot-Image des übergeordneten Builds statt von einer sauberen Basis. Das bedeutet:
* **Vererbte Workspaces** haben ihre Tools, Runtimes und Abhängigkeiten bereits installiert. Das System holt den neuesten Code (`git pull`) und führt `maintenance` aus, um Abhängigkeiten zu aktualisieren.
* **Neu erstellte Workspaces** werden von Grund auf eingerichtet — frisch geklont und mit der vollständigen Sequenz aus `initialize` + `maintenance`.
* **Entfernte Workspaces** werden aus ihren Verzeichnissen bereinigt.
Organisations- und Enterprise-Blueprints überspringen `initialize` bei differenziellen Builds (da die Tools bereits im übergeordneten Image vorhanden sind) und führen nur `maintenance` aus.
`$ENVRC` wird zu Beginn jedes Builds zurückgesetzt, einschließlich differenzieller Builds.
Umgebungsvariablen und `PATH`-Einträge, die von einem vorherigen
Build in `$ENVRC` geschrieben wurden, werden nicht übernommen. Wenn `maintenance` sie benötigt, muss es sie
selbst konfigurieren.
## Wann stattdessen ein vollständiger Build ausgeführt wird
Auch wenn differenzielle Builds aktiviert sind, greift das System in bestimmten Situationen auf einen vollständigen Build zurück:
* **Es gibt keinen übergeordneten Build** — erster Build oder alle vorherigen Builds sind fehlgeschlagen
* **Organization- oder Enterprise-Blueprint wurde geändert** — globale Änderungen betreffen alle Workspaces, daher ist ein vollständiger Neuaufbau sicherer
* **Die Reihenfolge der Repositorys wurde geändert** — da Repos von der Einrichtung anderer Repos abhängen können, löst eine Umordnung einen vollständigen Neuaufbau aus
* **Der übergeordnete Build ist zu alt oder inkompatibel** — das System prüft, ob der übergeordnete Build geeignet ist
Wenn ein Fallback erfolgt, zeigt die Build-Detailseite den Grund unter dem Badge für die Build-Art an.
## Build-Typ anzeigen
Nachdem ein Build abgeschlossen ist, können Sie sehen, ob es sich um einen **Differential**- oder **vollständiger Build**-Build handelt:
1. Gehen Sie zu **Settings > Environment > Snapshots**
2. Klicken Sie im Verlauf auf einen Build
3. Das Badge **Build kind** zeigt entweder **Differential** (blau) oder **vollständiger Build** (Standard) an
Bewegen Sie den Mauszeiger auf das Badge, um in einem Tooltip zu sehen, was die einzelnen Typen bedeuten:
* **Differential**: *"Nur geänderte Workspaces werden neu gebaut; unveränderte werden vom letzten erfolgreichen Build mit derselben Konfiguration übernommen"*
* **vollständiger Build**: *"Alle Workspaces werden von Grund auf neu gebaut"*
## Vorteile
| Vorteil | Beschreibung |
| ------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Schnellere Builds** | Nur geänderte Workspaces durchlaufen den vollständigen Einrichtungsprozess. Vererbte Workspaces überspringen `initialize` vollständig. |
| **Weniger Netzwerkauslastung** | Unveränderte Workspaces laden Tools, Runtimes oder große Abhängigkeiten nicht erneut herunter. |
| **Schnellere Iteration** | Wenn Sie den Blueprint eines einzelnen Repo überarbeiten, bremsen andere Repo den Build nicht aus. |
| **Gleiche Zuverlässigkeit** | Wenn etwas nicht stimmt, greift das System automatisch auf einen vollständigen Build zurück. Sie können außerdem jederzeit manuell einen vollständigen Build auslösen. |
## Vollständigen Build manuell auslösen
Auch wenn differenzielle Builds aktiviert sind, können Sie über die Schaltfläche **Build snapshot** einen vollständigen Build erzwingen. Verwenden Sie das Dropdown-Menü, um **vollständiger Build** statt der standardmäßigen differenziellen Option auszuwählen.
Wir empfehlen, regelmäßig einen vollständigen Build auszuführen, um übernommenen Zustand zu verwerfen und zu überprüfen, ob Ihre Blueprints die Umgebung weiterhin von Grund auf erstellen können. Führen Sie außerdem einen solchen Build aus, nachdem Sie Setup entfernt oder ersetzt haben, das möglicherweise veraltete Dateien, Tools oder Abhängigkeiten im Snapshot hinterlassen hat. Ein vollständiger Build führt alle `initialize`- und `maintenance`-Schritte erneut aus.
## FAQ
Nein. Sitzungen starten immer vom finalen Snapshot, unabhängig davon, wie er erstellt wurde. Der einzige Unterschied ist die Build-Geschwindigkeit.
Pinnen Sie unter **Settings > Environment > Snapshots** einen zuvor als funktionierend bekannten Build an und starten Sie dann einen vollständigen Build, um einen sauberen Snapshot zu erhalten. Sie können differenzielle Builds auch komplett deaktivieren, um wieder zu vollständigen Builds zurückzukehren.
Ja. Ein Build mit dem Status `partial` (einige Workspaces waren erfolgreich, andere sind fehlgeschlagen) kann als übergeordneter Build dienen. Das System übernimmt nur von Workspaces, die im übergeordneten Build erfolgreich waren.