DELIVERY · 05 / 06
Delivery ist der Teil der Softwareentwicklung, der sich am schlechtesten improvisieren lässt. Wir bauen Pipelines, Container-Images und deklarative Infrastruktur so, dass ein Release reproduzierbar aus einem Commit entsteht, im Betrieb messbar ist und sich im Fehlerfall umkehren lässt. Dazu gehört auch die Entscheidung, welche Werkzeuge ein Projekt nicht braucht.
Ausgangslage
Der häufigste Befund ist ein Build, der sich nicht wiederholen lässt. Abhängigkeiten werden ohne Lockfile aufgelöst, Basis-Images über den beweglichen Tag latest gezogen, und der Build-Agent trägt Werkzeuge in genau der Version, die vor zwei Jahren dort installiert wurde. Ein Artefakt aus dem Januar entsteht im Juli nicht mehr identisch aus demselben Commit. Damit ist jede Aussage über den Inhalt der laufenden Produktionsversion eine Vermutung.
Daneben steht das Deployment als Ritual: jemand verbindet sich per SSH, führt drei Skripte in der richtigen Reihenfolge aus und prüft danach von Hand, ob der Dienst antwortet. Das funktioniert, solange diese Person verfügbar ist. Rollback existiert selten als definierter Schritt, sondern als Rekonstruktionsversuch unter Zeitdruck. Freitags wird deshalb nicht ausgeliefert – ein zuverlässiges Symptom dafür, dass dem Prozess niemand traut.
Container-Images wachsen unbemerkt. Das Laufzeit-Image enthält Compiler, Paketmanager, Debug-Werkzeuge und den Git-Verlauf, läuft als root und bringt mehrere hundert Pakete mit, von denen der Dienst eine Handvoll benötigt. Jedes dieser Pakete erzeugt CVE-Meldungen, die niemand mehr bewertet. Gleichzeitig landen Zugangsdaten als Build-Argument in einem Layer und bleiben dort nachweisbar, auch wenn sie im finalen Dateisystem nicht mehr auftauchen.
Auf der Betriebsseite sehen wir zwei Extreme. Entweder fehlt Beobachtbarkeit fast vollständig: Logs liegen lokal auf den Hosts, Fehler melden Nutzer, über Latenzen existieren keine Zeitreihen. Oder es gibt hunderte Alarme, von denen ein Teil täglich feuert, sodass die Bereitschaft gelernt hat, sie zu ignorieren. Nicht selten läuft dazu ein Kubernetes-Cluster für drei Dienste, dessen Betrieb mehr Aufmerksamkeit verlangt als die Anwendung selbst.
Vorgehen
Wir beginnen beim Artefakt. Abhängigkeiten werden über Lockfiles festgeschrieben, Basis-Images per Digest referenziert statt per Tag, und der Build läuft in einer Umgebung, deren Inhalt selbst versioniert ist. Multi-Stage-Builds trennen Kompilierung von Laufzeit: ausgeliefert wird ein Image mit Binary, Zertifikatsspeicher und den nötigen Laufzeitbibliotheken, sonst nichts. Es startet unter einer unprivilegierten UID, wo möglich mit schreibgeschütztem Root-Dateisystem. Da Layer entlang der Dockerfile-Reihenfolge gecacht werden, stehen selten geänderte Schritte oben.
Die Pipeline liegt als Code im Repository – als .gitlab-ci.yml oder als Workflow unter .github/workflows – und durchläuft feste Stufen: Formatprüfung, Tests, Build, Abhängigkeits- und Image-Scan, Signatur, Deployment. Gebaut wird genau einmal. Dasselbe Image wandert per Digest durch Staging und Produktion, statt pro Umgebung neu zu entstehen. Ein SBOM entsteht im Build und wird mit dem Artefakt aufbewahrt, sodass die Frage nach einer betroffenen Bibliothek eine Abfrage ist und keine Recherche.
Infrastruktur wird deklariert, nicht geklickt. Provisionierung beschreiben wir mit OpenTofu beziehungsweise Terraform in versionierten Modulen, Konfiguration mit idempotenten Ansible-Rollen. Der Zustand liegt in einem Remote-Backend mit Locking, jede Änderung wird als Plan im Merge Request gelesen und erst danach angewendet. Wiederkehrende Plan-Läufe machen Drift sichtbar, also Abweichungen durch manuelle Eingriffe. Secrets bleiben außerhalb der Repositories: verschlüsselt mit SOPS und age oder in einem Secret-Store, für die Pipeline mit kurzlebigen OIDC-Tokens statt dauerhafter Zugangsschlüssel.
Für das Ausrollen wählen wir die einfachste Strategie, die das Risiko trägt. Rolling Updates mit ernst gemeinten Readiness-Probes genügen häufig. Blue/Green lohnt, wenn ein Umschalten am Reverse Proxy sauberer ist als ein gemischter Zustand. Canary passt dort, wo genug Verkehr für eine statistische Aussage anliegt – mit vorab definierten Abbruchkriterien aus Fehlerrate und Latenz. Datenbankmigrationen rollen wir nach dem Muster expand/contract zweistufig aus, damit alte und neue Version gleichzeitig lauffähig bleiben. Erst das macht Rollback zu einem einzelnen Schritt.
Leistungsumfang
01
02
03
04
05
06
07
Einsatzfälle
Auslieferung läuft über SSH, Shell-Skripte und eine Checkliste im Wiki, die eine Person im Kopf hat. Wir überführen den bestehenden Ablauf schrittweise in eine Pipeline mit Artefakt-Promotion, Health-Checks und definiertem Rollback.
Ein Laufzeit-Image von über einem Gigabyte, root als Nutzer, Build-Werkzeuge inklusive, Scanner-Report mit dreistelliger Zahl an Befunden. Wir zerlegen den Build in Stufen, pinnen die Basis und binden Scan und SBOM in die Pipeline ein.
Netze, Instanzen und Firewall-Regeln sind über die Web-Konsole entstanden, niemand kennt den Sollzustand. Wir übernehmen den Bestand per Import in OpenTofu-Module und machen jede weitere Änderung über Plan und Review nachvollziehbar.
Dashboards existieren, Alarme feuern regelmäßig, reagiert wird nicht mehr. Wir definieren Service-Level-Ziele, leiten daraus wenige belastbare Alarme ab und ergänzen Logs und Traces so, dass die Ursachensuche nicht bei der Grafik endet.
Ergebnis
Ablauf
Fragen
Häufig nicht. Für wenige Dienste mit überschaubarer Last trägt eine Kombination aus Container-Runtime, systemd-Units beziehungsweise Podman-Quadlets und einem Reverse Proxy sehr weit – bei deutlich geringerem Betriebsaufwand. Kubernetes lohnt, wenn viele Dienste, mehrere Teams, echte Autoskalierung oder eine bestehende Plattform es rechtfertigen. Wir bewerten das anhand Ihrer Last, Ihrer Teamgröße und der Frage, wer den Cluster später betreibt.
Ja. GitLab CI und GitHub Actions decken beide alles ab, was für reproduzierbare Builds, Scans und Deployments nötig ist; die Muster sind übertragbar. Ein Wechsel ist nur dann ein Thema, wenn konkrete Grenzen auftreten, etwa fehlende Runner-Isolation oder Lizenzmodelle, die Parallelität teuer machen.
Konfiguration wird verschlüsselt versioniert, üblicherweise mit SOPS und age, oder zur Laufzeit aus einem Secret-Store bezogen. Die Pipeline authentifiziert sich per OIDC gegen das Zielsystem und erhält ein kurzlebiges Token, statt einen dauerhaften Zugangsschlüssel gespeichert zu halten. Secrets werden nie als Build-Argument übergeben, weil sie sonst im Image-Layer nachweisbar bleiben.
Über zwei Schritte. Zuerst wird das Schema erweitert, sodass alte und neue Anwendungsversion gleichzeitig damit arbeiten können – neue Spalten nullable, keine Umbenennungen, Schreibpfade doppelt geführt. Nach dem Ausrollen und einer Beobachtungsphase entfernt ein zweiter Schritt die alten Strukturen. Ohne diese Trennung blockiert die Migration den Rollback.
Das hängt von den gewählten Bausteinen ab. Rechenleistung, Blockspeicher, S3-kompatibler Objektspeicher und managed PostgreSQL sind weitgehend austauschbar; proprietäre Funktionsplattformen, Event-Dienste und Identitätslösungen sind es nicht. Wir halten die Grenze bewusst und beschreiben Infrastruktur deklarativ, damit ein Wechsel eine Aufwandsfrage bleibt und keine Neuentwicklung.
Verwandte Leistungen
04 / 06
SYSTEMS
03 / 06
ARCHITECTURE
02 / 06
ENGINEERING
Fachartikel dazu
Continuous Integration, Delivery und Deployment sauber getrennt: Pipeline-Stufen mit Laufzeitzielen, Artefakt-Weitergabe, Rollback, Feature Flags und DORA-Metriken.
Was einen produktiven Container von einem Entwicklungscontainer unterscheidet: Multi-Stage-Builds, Digest-Pinning, PID 1, Secrets, Volumes und Ressourcenlimits.
Praxisleitfaden zur Basishärtung von Debian- und Ubuntu-Servern: SSH, nftables, unattended-upgrades, systemd-Sandboxing, sysctl, Logging und getestete Backups.
Kontakt
Beschreiben Sie kurz Ihr System und die offene Frage. Wir antworten mit einer fachlichen Einschätzung – ohne Vertriebsschleife.