Vier Schritte, vom Code zum Go-live
Ein freigegebener Merge-Request, ein nummeriertes Docker-Image, in der privaten Registry aufbewahrt und dann vom Controller ausgerollt; die Rückkehr zur vorherigen Version ist vorab festgehalten.
Referenz · interne Arbeit, Auslieferungskette
Unsere Auslieferungskette: jedes Go-live nummeriert, und ein vorab geschriebener Rollback.
Das ist kein Kundenauftrag, sondern die Werkzeugkette, die diese Website und die Projekte, die wir von unserer Forge aus liefern, online bringt. Jede Version wird zu einem nummerierten Docker-Image und ausgerollt, ohne dass ein Administratorschlüssel durch die Kette wandert. Die Rückkehr zur vorherigen Version erfordert keinen Neubau, und das Vorgehen ist schriftlich festgehalten.
01/AusgangslageWarum wir sie gebaut haben
Ein Go-live von Hand hängt vom Gedächtnis der Person ab, die es durchführt
Wir liefern zu zweit aus. Ein Go-live sollte immer denselben Weg nehmen, und wir wollten jederzeit wissen, welche Version läuft. Zu jedem Risiko, was die Kette tut.
- 01Jedes Go-live von Hand weicht ein wenig vom vorherigen ab.Immer derselbe Weg: Build des Images, Veröffentlichung in der Registry, Deployment auf Anforderung der Forge.
- 02Ein Image mit dem Tag „neueste Version“ sagt nicht, welcher Code läuft.Jedes Image trägt seine Versionsnummer und die Kennung seines Commits, im Image selbst eingetragen; keine wandernden Tags.
- 03Ein Rollback im Notfall zwingt dazu, eine Version neu zu bauen, die wir nicht mehr haben.Die Nummern folgen lückenlos aufeinander: Die vorherige verweist immer auf ein veröffentlichtes Image, das nur neu gestartet werden muss.
- 04Ein versehentlicher Push auf den Hauptzweig geht in Produktion: Das ist uns passiert.Der Hauptzweig ist in allen unseren aktiven Repositorys für direkte Pushes gesperrt: Alles läuft über einen Merge-Request mit grüner Pipeline, Administratoren eingeschlossen.
02/Was wir gebaut habenHeute im Einsatz
Vom Commit zum Go-live, ohne Handgriff
Ein Merge-Request wird freigegeben, der Hauptzweig liefert aus, und jeder Schritt hinterlässt eine Spur, die wir nachlesen können.
- 01Selbst gehostete Forge. Code, Merge-Requests, Pipeline und Image-Registry auf unserer eigenen Forgejo-Forge.
- 02Prüfen, ohne auszuliefern. Ein Merge-Request baut das Image, um zu prüfen, ob es durchläuft, ohne es zu veröffentlichen oder auszurollen.
- 03Versionsnummer. Das Datum, dann die laufende Nummer der Veröffentlichung am Tag, vor dem Build reserviert, damit kein Image ein anderes überschreibt.
- 04Mehrstufiges Docker-Image. Abhängigkeiten, Build und Ausführung getrennt; das fertige Image läuft ohne Privilegien, mit einem Healthcheck.
- 05Ein Image, das weiß, woher es kommt. Ursprungs-Commit und Versionsnummer stehen in seinen Labels: Der Container selbst sagt, was läuft.
- 06Deployment per Controller. Die Forge fordert das Go-live bei einem Controller an, mit einem eigenen Schlüssel; die Secrets der Anwendung bleiben auf dem Server, nie im Repository.
- 07Schriftlicher Rollback. Die gewünschte Nummer eintragen, neu starten, am Container prüfen; eine fehlende Nummer lässt den Befehl scheitern, ohne die laufende Website anzutasten.
- 08Schutzmechanismen. Geschützter Hauptzweig in allen aktiven Repositorys; jeden Montag werden die tatsächlich laufenden Images analysiert, und die Zahl der kritischen Schwachstellen kommt per E-Mail.
03/Ein SchemaAls Text gesetzt, kein Screenshot
Ein Schema des Ablaufs, bis ein Screenshot unserer Forge vorliegt
Noch ist kein Screenshot der Forge veröffentlicht. Dieses Schema folgt einem Go-live, vom Code bis zum Server.
04/TechnologienWas wir gewählt haben und warum
Eine kurze Kette, die wir von Anfang bis Ende nachlesen können
Wenige Werkzeuge, und jede Regel steht im Repository, neben dem Code, den sie ausliefert.
- ForgeForgejo mit Forgejo Actions als Pipeline, private Image-Registry auf derselben Forge.
- ImagesMehrstufige Docker-Builds, Ausführung ohne Privilegien, Healthcheck, Labels für Commit und Version.
- DeploymentDocker Compose auf dem Server, Versionsnummer aus einer einzigen Datei gelesen; ein fehlender Wert lässt den Befehl scheitern, statt ein beliebiges Image auszuliefern.
- ZugriffDeployment-Controller über einen Schlüssel erreichbar, der nur zum Auslösen dient; Secrets der Anwendung auf dem Server, außerhalb des Repositorys.
- KontrollenGeschützter Hauptzweig in allen aktiven Repositorys, grüne Pipeline vor dem Merge, Administratoren eingeschlossen.
- ÜberwachungWöchentliche Analyse der laufenden Images mit Trivy, Bericht per E-Mail und Auditbericht als PDF.
05/WeiterführendVerwandte Leistung und der Blog
Für Software, die mit ihrer Auslieferungskette kommt
Und jetzt
Go-lives von Hand, und niemand weiß, welche Version läuft?
Jede Software, die wir schreiben, kommt mit ihrer Auslieferungskette. Beschreiben Sie uns Ihr Projekt, wir sagen Ihnen, was machbar ist, mit Zeitrahmen und Preisrahmen.
Ihr Projekt besprechen
Antwort binnen 24 Stunden an Werktagen, von einem der beiden Gründer. Oder telefonisch: +33 7 59 96 14 99.