Differenzielle Builds

​

Ü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

​

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) mit einem Snapshot-Image für dieselbe Plattform und Maschinenkonfiguration, 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 und Secrets — und prüft, was sich geändert hat.

​

3. Workspace-Aktionen zuweisen

Auf Grundlage des Vergleichs erhält jeder Workspace eine von drei Aktionen:

​

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.

​

Wann stattdessen ein vollständiger Build ausgeführt wird

Auch bei aktivierten differenziellen Builds wird ein Build in diesen Situationen als vollständiger Build ausgeführt:

• Sie fordern einen vollständigen Build an — Sie wählen im Dropdown Build snapshot die Option Vollständiger Build aus
• Der neueste vollständige Build ist zu alt — ein automatischer Build, etwa ausgelöst durch das Speichern eines Blueprints, läuft als vollständiger Build, wenn für seine Plattform kein vollständiger Build vorhanden ist oder der neueste älter ist als das Intervall Aktualisierung vollständiger Builds unter Settings > Environment > Advanced (standardmäßig alle 7 Tage)
• Es ist kein wiederverwendbarer übergeordneter Build vorhanden — es gibt keinen Build mit dem Status success oder partial mit einem Snapshot-Image für dieselbe Plattform und Maschinenkonfiguration
• Der übergeordnete Build ist inkompatibel — Plattform, Maschinenkonfiguration, Basis-Image oder die Einstellung Clone repositories on all platforms haben sich seit dem übergeordneten Build geändert, oder der übergeordnete Build hat keine Secret-Ausgangsbasis für den Vergleich
• Die Organisations- oder Enterprise-Konfiguration hat sich geändert — ein Organisations- oder Enterprise-Blueprint, eine Blueprint-Datei oder ein Secret hat sich seit dem übergeordneten Build geändert

Änderungen, die sich nur auf einzelne Repositorys beziehen, lassen den Build differenziell bleiben. Neue Repositorys, Blueprint- oder Secret-Änderungen für ein Repository sowie Repositorys, die im übergeordneten Build fehlgeschlagen sind, werden innerhalb des differenziellen Builds neu gebaut. Das Neuanordnen von Repositorys löst keinen vollständigen Build aus. Wenn ein als differenziell angeforderter Build stattdessen als vollständiger Build ausgeführt wird, nennt der Tooltip Build kind auf der Build-Detailseite den Grund.

​

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

​

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