CI/CD im Mittelstand: automatisch ausliefern ohne Konzern-Apparat

Was muss eine Auslieferungsstrecke mindestens leisten?

CI steht für kontinuierliche Integration: Jede Codeänderung wird sofort mit dem Stand der anderen zusammengeführt und automatisch überprüft. CD steht für kontinuierliche Auslieferung: Der geprüfte Stand ist jederzeit auslieferbar, auf Knopfdruck oder automatisch.

Dahinter steckt kein bestimmtes Werkzeug, sondern eine Abfolge, die immer gleich läuft und die niemand von Hand ausführt. Drei Schritte reichen als Kern:

• Bauen: Aus dem Quellcode entsteht ein fertiges, versioniertes Artefakt — immer auf dieselbe Weise, unabhängig vom Rechner der einzelnen Entwicklerin.
• Prüfen: Automatische Tests, eine Kontrolle der Abhängigkeiten auf bekannte Sicherheitslücken und formale Codeprüfungen laufen durch.
• Ausliefern: Das geprüfte Artefakt wird auf eine Umgebung gespielt und dabei nachvollziehbar protokolliert.

Alles Weitere — Datenbankänderungen, Benachrichtigungen, automatische Lizenzprüfungen — kommt später dazu. Der Nutzen entsteht schon beim Kern: Niemand kopiert mehr Dateien von einem Laptop auf einen Server, und niemand vergisst einen Schritt, weil gerade Freitag ist.

Zwei Eigenschaften trennen eine brauchbare Strecke von einer lästigen. Erstens die Laufzeit: Braucht ein Durchlauf länger als etwa zehn Minuten, warten Menschen nicht mehr auf das Ergebnis und arbeiten parallel weiter — die Rückmeldung verliert ihren Wert. Zweitens die Verlässlichkeit: Eine Strecke, die gelegentlich grundlos scheitert, wird umgangen, und dann liefert doch wieder jemand von Hand aus.

Welche Umgebungen brauchen Sie wirklich?

Drei genügen fast immer. Mehr Umgebungen bedeuten mehr Pflege, mehr Datenstände und mehr Rückfragen, welcher Stand gerade wo läuft.

• Entwicklung: läuft lokal oder auf einem gemeinsamen Server und darf jederzeit kaputt sein.
• Vorschau beziehungsweise Abnahme: entspricht der Produktion so weit wie möglich, hier prüft der Fachbereich.
• Produktion: der echte Betrieb, mit echten Daten und echten Nutzern.

Die Vorschauumgebung ist die wichtigste und wird am häufigsten eingespart. Ohne sie prüft der Fachbereich entweder gar nicht oder direkt in der Produktion — beides endet vorhersehbar.

Halten Sie die Umgebungen technisch gleich und nur in den Daten verschieden. Abweichende Versionen von Datenbank, Laufzeitumgebung oder Betriebssystem erzeugen genau die Sorte Fehler, die im Gespräch „bei mir läuft es doch“ heißt.

Klären Sie außerdem früh, woher die Vorschauumgebung ihre Daten bezieht. Eine leere Datenbank taugt nicht zur Beurteilung, eine ungefilterte Kopie der Produktion ist datenschutzrechtlich heikel und schnell veraltet. Ein regelmäßig erzeugter, verfremdeter Auszug ist der übliche Kompromiss — einmal eingerichtet, läuft er ohne weiteres Zutun.

Wozu ein eigenes Deployment für jede einzelne Änderung?

Ein Vorschau-Deployment ist eine wegwerfbare, vollständige Instanz der Anwendung. Sie entsteht automatisch für einen einzelnen Änderungszweig und verschwindet, sobald dieser zusammengeführt wurde. Wer die Änderung beurteilen soll, bekommt eine eigene Adresse statt einer Beschreibung.

Für die Zusammenarbeit ist das der größte einzelne Fortschritt. Ein Handwerksbetrieb, der ein neues Formular für Wartungsaufträge freigeben soll, klickt es durch — er liest keine Änderungsliste und interpretiert keine Bildschirmfotos.

Achten Sie darauf, dass diese Instanzen wirklich wieder verschwinden. Vergessene Vorschauumgebungen kosten Rechenzeit, halten veraltete Datenbestände vor und werden gelegentlich mit der Produktion verwechselt. Ein automatisches Aufräumen nach der Zusammenführung oder nach einigen Tagen Untätigkeit gehört zur Grundausstattung.

Die Änderungszweige selbst sollten kurzlebig sein. Ein Zweig, der zwei Wochen offen steht, sammelt Konflikte an und macht die automatische Prüfung wertlos, weil sie einen Zustand testet, den es so nicht mehr gibt.

Soll die Auslieferung in die Produktion automatisch laufen?

Für die meisten mittelständischen Anwendungen: nein. Ein vollautomatischer Produktivgang bei jeder Zusammenführung setzt breite Testabsicherung, gute Überwachung und eine geregelte Bereitschaft voraus. Fehlt eines davon, tauschen Sie Bequemlichkeit gegen Risiko.

Die pragmatische Variante ist ein Halt vor dem letzten Schritt: Alles bis zur Vorschau läuft automatisch, der Produktivgang braucht eine bestätigende Person. Das dauert zehn Sekunden und hält die Verantwortung dort, wo sie hingehört.

• Legen Sie fest, wer freigeben darf, und hinterlegen Sie das technisch, nicht nur als Absprache.
• Protokollieren Sie jede Freigabe mit Person, Zeitpunkt und Versionsnummer.
• Vermeiden Sie den Freitagnachmittag als gewohnten Auslieferungszeitpunkt.
• Definieren Sie einen Ausnahmeweg für dringende Fehlerbehebungen, damit im Ernstfall niemand improvisiert.

Wie liefern Sie ohne Ausfallzeit aus und wie kommen Sie zurück?

Grundlage für beides ist Versionierung: Jedes ausgelieferte Artefakt trägt eine eindeutige Nummer und bleibt aufbewahrt. Zurückgehen heißt dann, eine vorherige Version erneut auszurollen — kein Zurückbauen von Code unter Zeitdruck.

Ausfallfreie Auslieferung erreichen Sie über ein zweites Set laufender Instanzen: Die neue Version startet parallel, wird geprüft, dann leitet der vorgeschaltete Verteiler den Verkehr um. Fällt etwas auf, geht der Verkehr zurück auf die alte Seite, während beide noch stehen.

• Bewahren Sie mindestens die letzten fünf Versionen auslieferbar auf.
• Messen Sie, wie lange ein Rücksprung dauert; unter fünf Minuten ist ein gutes Ziel.
• Behandeln Sie Datenbankänderungen getrennt — sie lassen sich selten so leicht zurücknehmen wie Programmcode.
• Bringen Sie Datenbankänderungen vorwärtskompatibel ein: erst das neue Feld anlegen, dann den Code ausliefern, der es nutzt.

Ergänzend hilft ein kurzer Blick nach der Auslieferung, statt sofort weiterzuarbeiten. Fünf Minuten auf Fehlerrate und Antwortzeit zu schauen, ist billiger als die Meldung eines Kunden am nächsten Vormittag. Wo eine Überwachung besteht, lässt sich dieser Blick automatisieren: Steigen die Fehler nach dem Ausrollen deutlich an, schaltet die Strecke von selbst zurück.

Wer nicht innerhalb von Minuten auf die Vorversion zurückkann, liefert nicht aus, sondern hofft.

Wo bewahren Sie Zugangsdaten und Geheimnisse auf?

Nicht im Code, nicht in der Versionsverwaltung, nicht in einer Textdatei auf dem Server. Zugangsdaten für Datenbanken, Zahlungsdienste, Mailversand und Schnittstellen gehören in eine dafür gedachte Ablage, aus der die Auslieferungsstrecke sie zur Laufzeit bezieht.

• Jede Umgebung bekommt eigene Zugangsdaten; ein Vorschausystem darf nie an die Produktionsdatenbank.
• Zugriff wird pro Person vergeben und beim Ausscheiden entzogen — anhand einer Liste, die jemand tatsächlich pflegt.
• Geheimnisse werden turnusmäßig gewechselt, mindestens jährlich und sofort bei Personalwechsel an sensibler Stelle.
• Protokolle und Fehlermeldungen dürfen keine Zugangsdaten enthalten; prüfen Sie das einmal aktiv nach.

Ein SaaS-Anbieter mit einem Dutzend Integrationen kommt an einer geordneten Geheimnisverwaltung ohnehin nicht vorbei. Aber auch bei drei Zugängen lohnt sie sich, weil sie eine Frage beantwortet, die sonst niemand beantworten kann: Wer hat eigentlich noch Zugriff?

Denken Sie an den Fall, dass ein Geheimnis doch einmal nach außen gelangt — in einem Bildschirmfoto, einer Chatnachricht, einem öffentlich gewordenen Repository. Der Ablauf sollte vorher feststehen: Zugang sofort ungültig setzen, neuen erzeugen, ausrollen, Zugriffe der letzten Tage sichten. Wer das erst im Ernstfall zusammensucht, verliert Stunden, in denen der alte Zugang weiter gültig ist.

Was kostet das, welches Werkzeug nehmen Sie, und ab wann lohnt es sich?

Die Ersteinrichtung einer schlanken Strecke für eine Webanwendung liegt typischerweise bei zwei bis fünf Personentagen. Kommen mehrere Dienste, Datenbankmigrationen und ausfallfreie Auslieferung dazu, sind acht bis fünfzehn Tage realistisch. Der laufende Betrieb kostet wenig Geld, aber regelmäßige Aufmerksamkeit: Abhängigkeiten veralten, Zugänge laufen ab.

Bei den Werkzeugen gilt: Nehmen Sie das, was neben Ihrer Versionsverwaltung ohnehin bereitsteht. Wer den Code bei einem Anbieter liegen hat, der eine integrierte Strecke mitbringt, spart sich einen zweiten Dienst, zweite Zugänge und zweite Rechnungen. Ein selbst betriebener Server dafür rechnet sich erst bei besonderen Anforderungen an Datenhaltung oder Rechenzeit.

Der Nutzen skaliert mit zwei Größen: Teamgröße und Änderungsfrequenz. Ab etwa drei Personen am selben Code oder ab wöchentlichen Änderungen an einer produktiv genutzten Anwendung amortisiert sich die Einrichtung binnen weniger Monate. Bei einer Anwendung, die zweimal im Jahr angefasst wird und die eine Person betreut, ist eine gut dokumentierte Auslieferungsanleitung die ehrlichere Antwort.

• Wenige Änderungen, eine Person: schriftliche Anleitung, versionierte Artefakte, kein Automat.
• Regelmäßige Änderungen, kleines Team: Bauen und Prüfen automatisch, Produktivgang per Klick.
• Tägliche Änderungen, mehrere Teams: zusätzlich Vorschauumgebungen je Zweig und ausfallfreie Auslieferung.