Zum Hauptinhalt springen

​
Ü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

1

Zu den Umgebungseinstellungen gehen

Gehen Sie zu Settings > Environment > Snapshots.
2

Den Schalter aktivieren

Aktivieren Sie den Schalter differenzielle Builds. Die Beschreibung lautet: „Schnellere Builds durch Wiederverwendung unveränderter Workspaces.“
3

Einen Build auslösen

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:
AktionWas passiertWann sie zum Einsatz kommt
RebuildRepo klonen und alle Blueprint-Schritte (initialize + maintenance) von Grund auf ausführenDer Blueprint wurde seit dem übergeordneten Build geändert
InheritDen neuesten Code abrufen und nur maintenance-Schritte ausführenDer Blueprint ist unverändert — das Setup des übergeordneten Builds wiederverwenden
RemoveDen Workspace aus dem Snapshot löschenDer 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

VorteilBeschreibung
Schnellere BuildsNur geänderte Workspaces durchlaufen den vollständigen Einrichtungsprozess. Vererbte Workspaces überspringen initialize vollständig.
Weniger NetzwerkauslastungUnveränderte Workspaces laden Tools, Runtimes oder große Abhängigkeiten nicht erneut herunter.
Schnellere IterationWenn Sie den Blueprint eines einzelnen Repo überarbeiten, bremsen andere Repo den Build nicht aus.
Gleiche ZuverlässigkeitWenn 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.