Ein Deployment-Artefakt ist das fertige Paket aus einem Build, das unverändert auf die Server geht. Es trägt eine Fassung, eine Prüfsumme und den Commit, aus dem es entstand.
- Deployment-Artefakt
Das fertige Paket aus einem Build, das unverändert auf die Server geht.
Beispiel: „Dasselbe Deployment-Artefakt lief zuerst auf der Testumgebung und zwei Tage später außen.“Üblich sind drei Formen: ein Archiv als tar oder zip, ein Container-Abbild oder ein ganzes Verzeichnis, das als Release abgelegt wird.
Abgrenzung zum Build: Dieser ist der Vorgang. Das Artefakt ist, was dabei herauskommt und aufbewahrt wird.
Warum ein Artefakt einmal gebaut und mehrfach ausgerollt wird
Damit überall dasselbe läuft. Wer für die Testumgebung und für außen getrennt baut, prüft am Ende zwei verschiedene Ergebnisse, und der Unterschied steckt in einem Paket, das zwischen beiden Läufen eine neue Fassung bekam.
Mit einem Artefakt verschiebt sich die Prüfung dorthin, wo sie hingehört: Geprüft wird das Paket, das später ausgeliefert wird, und nicht ein Geschwister davon.
Was in ein Deployment-Artefakt gehört
Der Code, die aufgelösten Abhängigkeiten und die gebauten Dateien für den Browser. Draußen bleiben Zugangsdaten, Konfiguration je Umgebung und alles, was sich zwischen Testsystem und Betrieb unterscheidet.
Diese Trennung ist der Grund, warum Konfiguration über Umgebungsvariablen kommt. Dasselbe Paket läuft dadurch an zwei Orten mit zwei Datenbanken, siehe Umgebungsvariablen.
Wo Artefakte liegen
In einem Speicher, der Fassungen aufbewahrt: ein Verzeichnis auf dem Server, ein Paketspeicher der Pipeline oder eine Registry für Container-Abbilder. Entscheidend ist, dass die letzten Stände abrufbar bleiben.
Denn genau darauf stützt sich der Rückweg. Ein Rollback ist das Ausrollen des vorherigen Artefakts, und ohne aufbewahrte Pakete wird daraus ein neuer Build mit ungewissem Ergebnis.