Einen Build durch die Umgebungen befördern: Konfigurationsübernahme und Dev-Prod-Parität

Ziel

Jede Umgebung führt ein Artefakt aus, das genau einmal gebaut wurde, sodass ein Fehler in der Produktion nicht mit einem anderen Compiler, einer anderen Abhängigkeitsauflösung oder einem anderen Build-Flag erklärt werden kann, und jeder Unterschied zwischen Umgebungen ein expliziter Konfigurationswert ist.

Voraussetzungen

Ein Build, der ein unveränderliches Artefakt erzeugt (Container-Image nach Digest, versioniertes Paket), und eine Laufzeitumgebung, die Konfiguration aus der Umgebung oder aus eingehängten Dateien liest, im Sinne der Twelve-Factor-Trennung von Konfiguration und Code (zitiert).

Schritte

1. Pro Commit einmal in der CI bauen und das Artefakt unter einer Identität veröffentlichen, die nie überschrieben wird; Digest oder Prüfsumme festhalten.
2. Das Release als Artefakt plus Konfiguration definieren: Gemäss dem zitierten Build-Release-Run-Faktor kombiniert ein Release den Build mit der Konfiguration des Deployments und sollte eine eindeutige Release-ID besitzen; daher die umgebungsspezifischen Konfigurationsdateien versionieren und jedes Deployment als artifact@digest + config@revision benennen.
3. Die umgebungsspezifische Konfiguration auf die Werte beschränken, die sich zwingend unterscheiden müssen: Endpunkte, Zugangsdaten, Kapazität, Standardwerte von Feature-Schaltern. Alles andere, das abweicht, ist eine zu beseitigende Paritätslücke.
4. Befördern, indem dasselbe Artefakt neu getaggt oder neu referenziert wird, nie durch einen erneuten Build aus demselben Branch; ein erneuter Build gilt bis zum Gegenbeweis als ein anderer Build.
5. Backing Services angleichen: Der zitierte Dev/Prod-Paritätsfaktor verlangt, Entwicklung, Staging und Produktion so ähnlich wie möglich zu halten – in der Zeit (bald nach dem Schreiben deployen), beim Personal (Entwickler deployen) und bei den Werkzeugen (dieselben Backing Services statt leichtgewichtiger lokaler Ersatzlösungen); der Faktor warnt, dass schon kleine Inkompatibilitäten zwischen Backing Services dazu führen können, dass Code, der in der Entwicklung funktionierte, in der Produktion scheitert. Lokal und in der CI dieselbe Engine und Version in Compose betreiben.
6. Jede Beförderung an Prüfungen koppeln, die in der vorherigen Umgebung gegen genau dieses Artefakt gelaufen sind, und festhalten, welches Artefakt wo aktiv ist.
7. Konfiguration zwischen Umgebungen regelmässig per Diff vergleichen und jede abweichende Zeile begründen.

Erwartetes Ergebnis

«Es hat im Staging funktioniert» wird zu einer belastbaren Aussage, weil im Staging dieselben Bytes mit einer Konfiguration liefen, die sich nur in aufgelisteten Werten unterscheidet. Ein Rollback ist eine Beförderung des vorherigen Artefakts, kein erneuter Build.

Grenzen und Prüfbasis

Parität bei Datenvolumen, Verkehrsform und Drittanbieter-Sandboxes ist selten erreichbar; die Beförderung beseitigt Build-Varianz, nicht Umgebungsvarianz. Konfigurationswerte, die Codepfade verändern (Schalter), führen ungetestete Kombinationen wieder ein und müssen als Teil des Release behandelt werden. Die Anleitung folgt den zitierten Faktoren; es wird keine Messung behauptet.