Warum Sie niemals für die Produktion neu bauen sollten

Vor einigen Wochen hatte ein Team, mit dem ich zusammenarbeitete, ein seltsames Problem. Ihre Staging-Umgebung bestand alle Tests. Das QA-Team gab grünes Licht. Der Product Owner gab die Freigabe. Doch als sie in die Produktion deployeden, sahen die Benutzer Fehler, die während der Tests nie aufgetreten waren.

Das Team verbrachte zwei Tage mit der Fehlersuche. Sie verglichen Konfigurationsdateien, überprüften Umgebungsvariablen und sahen sich die Codeänderungen an. Alles sah identisch aus. Schließlich fiel jemandem auf, dass die Build-Zeitstempel unterschiedlich waren. Das Artefakt, das in der Produktion lief, war nicht dasselbe Artefakt, das alle Tests im Staging bestanden hatte.

Diese Geschichte wiederholt sich täglich in vielen Teams. Die Ursache ist fast immer dieselbe: Irgendwo zwischen Staging und Produktion hat jemand beschlossen, die Anwendung neu zu bauen, anstatt das vorhandene Artefakt zu promoten.

Die zwei Wege: Neu bauen vs. Promoten

Jede Software-Delivery-Pipeline hat mehrere Umgebungen. Entwicklung zum Ausprobieren neuer Funktionen. Staging zur Verifizierung durch QA oder Product Owner. Produktion, in der echte Benutzer mit Ihrer Anwendung interagieren.

Wenn Sie ein Artefakt von einer Umgebung in die nächste verschieben müssen, haben Sie zwei Möglichkeiten.

Neu bauen bedeutet, den Quellcode von einem bestimmten Commit zu nehmen und den Build-Prozess für die Zielumgebung erneut auszuführen. Die Pipeline checkt den Code aus, lädt Abhängigkeiten herunter, kompiliert die Anwendung und erzeugt ein neues Artefakt.

Das folgende Flussdiagramm veranschaulicht die beiden Wege und ihre Ergebnisse:

flowchart TD A[Start: Deployment in Produktion nötig] --> B{Weg wählen} B --> C[Neu bauen] B --> D[Promoten] C --> E[Quellcode auschecken] E --> F[Abhängigkeiten herunterladen] F --> G[Anwendung kompilieren] G --> H[Neues Artefakt mit neuer Prüfsumme & Zeitstempel] H --> I[In Produktion deployen] I --> J[Risiko: unterscheidet sich vom getesteten Artefakt] D --> K[Vorhandenes Artefakt im Registry] K --> L[Als für Produktion freigegeben markieren] L --> M[Gleiche Bytes in Produktion deployen] M --> N[Gewissheit: entspricht getestetem Artefakt]

Promoten bedeutet, das Artefakt zu nehmen, das bereits in Ihrem Registry existiert, das bereits gebaut und in einer vorherigen Umgebung verifiziert wurde, und es als für die nächste Umgebung freigegeben zu markieren. Kein neuer Build. Keine neue Kompilierung. Nur eine Metadatenänderung, die besagt: "Dieses Artefakt ist jetzt in der Produktion erlaubt."

Diese beiden Ansätze klingen ähnlich, führen aber zu grundlegend unterschiedlichen Ergebnissen.

Das versteckte Risiko des Neubauens

Wenn Sie für die Produktion neu bauen, erstellen Sie ein neues Artefakt. Es hat eine andere Build-ID. Einen anderen Zeitstempel. Und entscheidend: Die während dieses neuen Builds heruntergeladenen Abhängigkeiten könnten sich von denen unterscheiden, die im Staging-Build verwendet wurden.

Stellen Sie sich vor, was passiert, wenn Ihr Build-Prozess npm install, pip install oder go mod download ausführt. Diese Befehle greifen auf entfernte Repositories zu, um Pakete zu holen. Wenn ein Paketbetreuer zwischen Ihrem Staging-Build und Ihrem Produktions-Build ein kleines Update veröffentlicht, wird Ihr Produktions-Artefakt dieses Update enthalten. Selbst wenn die Änderung technisch abwärtskompatibel ist, führt sie zu einem Unterschied zwischen dem, was Sie getestet haben, und dem, was Sie in der Produktion ausführen.

Das gleiche Risiko gilt für Ihre Toolchain. Wenn Ihr CI-System zwischen den Builds die Compiler-Version, das Basis-Image oder die Build-Tools aktualisiert, kann sich die Ausgabe auf subtile Weise ändern. Code, der während des Staging-Builds einwandfrei kompilierte, könnte während des Produktions-Builds andere Maschineninstruktionen erzeugen.

Sie verlieren die Gewissheit, dass das, was getestet wurde, auch das ist, was in der Produktion läuft. Sie wechseln von Vertrauen zu Hoffnung.

Warum Promoten besser funktioniert

Promoten beseitigt diese Unsicherheit. Das Artefakt wird einmal gebaut, in Ihrem Registry gespeichert und im Staging verifiziert. Wenn es alle Prüfungen besteht, promoten Sie es in die Produktion, indem Sie seine Metadaten oder Tags aktualisieren. Keine neue Kompilierung. Keine neuen Abhängigkeits-Downloads. Die exakt gleichen Bytes, die im Staging liefen, laufen jetzt in der Produktion.

In der Praxis funktioniert Promoten normalerweise über Tagging. In einem Container-Registry könnten Sie ein Image mit dem Tag staging haben. Nach der Verifizierung fügen Sie demselben Image ein Tag production hinzu. Das Image selbst ändert sich nicht. Nur die Labels ändern sich. Ihr Deployment-System überwacht das production-Tag und zieht das Image, sobald es erscheint.

Dieser Ansatz vereinfacht auch Rollbacks. Wenn die neue Version in der Produktion Probleme verursacht, zeigen Sie auf das zuvor promotete Artefakt zurück. Sie müssen nicht von einem alten Commit neu bauen und hoffen, dass die Abhängigkeiten und die Toolchain von vor drei Monaten noch verfügbar sind. Das alte Artefakt ist bereits in Ihrem Registry, genau so, wie es war, als es zuvor promotet wurde.

Verifizierung findet vor dem Promoten statt

Promoten bedeutet nicht, die Verifizierung zu überspringen. Bevor ein Artefakt vom Staging in die Produktion wechselt, sollte es eine definierte Reihe von Tests bestehen. Unit-Tests, Integrationstests und alle umgebungsspezifischen Prüfungen, die für Ihre Anwendung sinnvoll sind. Diese Tests laufen gegen das Artefakt im Staging. Wenn sie bestehen, wird das Artefakt promotet. Wenn sie fehlschlagen, bleibt das Artefakt im Staging, und das Team behebt den Quellcode, baut neu und startet den Verifizierungsprozess erneut.

Der entscheidende Unterschied ist, dass Verifizierung und Promoten dasselbe Artefakt verwenden. Sie testen nicht eine Version und deployen eine andere.

Wann ein Neubau notwendig sein kann

Es gibt legitime Fälle, in denen ein Neubau die richtige Wahl ist. Wenn Ihr Artefakt umgebungsspezifische Konfigurationen enthält, die in den Build eingebettet werden müssen, benötigen Sie möglicherweise separate Builds für jede Umgebung. Wenn Ihre Compliance-Anforderungen vorschreiben, dass Produktions-Artefakte in einer separaten, sichereren Pipeline gebaut werden müssen, müssen Sie möglicherweise neu bauen.

Aber diese Fälle sind Ausnahmen, nicht die Regel. Die meisten Teams können Konfiguration von Code trennen. Die meisten Compliance-Anforderungen können erfüllt werden, indem Artefakte nach dem Promoten signiert werden, anstatt sie neu zu bauen. Wenn Sie feststellen, dass Sie regelmäßig für die Produktion neu bauen, fragen Sie sich, ob der Grund technische Notwendigkeit oder nur Gewohnheit ist.

Praktische Checkliste für Artefakt-Promotion

Bevor Sie Ihren Promotion-Workflow einrichten, überprüfen Sie diese Punkte:

  • Ihr Build-Prozess erzeugt ein einzelnes Artefakt, das umgebungsübergreifend funktioniert
  • Ihr Registry unterstützt Tagging oder Metadaten-Updates ohne erneutes Hochladen
  • Ihr Deployment-System kann Tag-Änderungen überwachen und Deployments auslösen
  • Ihr Rollback-Prozess referenziert zuvor promotete Artefakte, nicht alte Commits
  • Ihr Team versteht, dass "Promoten" das Ändern von Metadaten bedeutet, nicht das Neubauen

Die konkrete Erkenntnis

Die Entscheidung zwischen Neubau und Promoten läuft auf eine Frage hinaus: Wollen Sie sicher sein, dass das, was Sie getestet haben, auch das ist, was Sie deployed haben, oder wollen Sie hoffen, dass der neue Build das gleiche Ergebnis liefert?

Promoten gibt Ihnen Gewissheit. Neubau gibt Ihnen Hoffnung. In der Produktion zählt Gewissheit mehr als Hoffnung. Bauen Sie einmal, verifizieren Sie gründlich, promoten Sie zuversichtlich. Ihre Benutzer werden es Ihnen danken, und Ihre Debugging-Sitzungen werden kürzer sein.