Continuous Integration und Delivery verstehen

Continuous Integration und Delivery verstehen

0:00 Willkommen zum ersten Modul. Wir sprechen drei Tage lang über GitHub Actions, und wir beginnen bewusst nicht mit YAML. Denn eine Pipeline zu bauen ist einfach; eine zu bauen, der ein Team vertraut, ist die eigentliche Aufgabe. In diesem Modul klären wir die Begriffe, die den Rest tragen: Was heißt Continuous Integration, was Delivery, was Deployment — und wo genau verläuft die Grenze zwischen ihnen.

0:23 Danach sehen wir uns die Bausteine von GitHub Actions an und die Architekturen, die sich in der Praxis bewährt haben. Am Ende steht eine Bestandsaufnahme unseres Beispielprojekts. Von dort aus wächst über sechzehn Module eine vollständige Pipeline.

Continuous Integration und Delivery verstehen

0:38 Der erste Tag hat ein Ziel: vom leeren Repository zu einer Pipeline, die bei jeder Änderung anspringt und schnell Bescheid gibt. Wir starten mit den Grundbegriffen, schreiben dann den ersten Workflow, schneiden seine Auslöser zu, reichen Werte zwischen Jobs weiter und machen das Ganze am Ende schnell genug, dass niemand darauf wartet.

0:56 Alles, was heute entsteht, bleibt bis zum dritten Tag in Gebrauch.

Continuous Integration, Delivery und Deployment

1:00 Fangen wir mit den drei Begriffen an, die im Alltag ständig durcheinandergehen. Sie klingen ähnlich, aber sie beschreiben drei verschiedene Versprechen — und nur eines davon nimmt dem Menschen die letzte Entscheidung ab. Stellen Sie sich eine Bäckerei vor. Continuous Integration heißt: Jede Zutat wird beim Hereinkommen geprüft, nicht erst beim Backen.

1:21 Continuous Delivery heißt: Der Teig ist jederzeit fertig, das Blech könnte sofort in den Ofen — aber jemand entscheidet, wann. Continuous Deployment nimmt auch diese Entscheidung heraus: Was die Prüfung besteht, geht direkt in den Verkauf. Technisch ist der Unterschied zwischen den letzten beiden winzig, organisatorisch ist er groß.

1:41 Die meisten Teams, die sagen, sie machen Continuous Deployment, machen in Wahrheit Delivery mit einem Knopf. Das ist völlig in Ordnung — man sollte es nur wissen und benennen. Diese Kette ist das Skelett jeder Pipeline, die wir in den nächsten drei Tagen bauen. Interessant ist weniger die Reihenfolge — die leuchtet sofort ein — als die Frage, wo Sie stehenbleiben. Jeder Pfeil ist eine Stelle, an der ein Mensch eingreifen kann oder muss.

2:07 Und jeder Kasten kostet Zeit, die zwischen dem Commit und der Rückmeldung liegt. Behalten Sie im Kopf: Der Abstand zwischen dem ersten und dem letzten Kasten ist die Zahl, die für Ihr Team wirklich zählt. Alles, was wir an Matrix Builds, Caches und Parallelität besprechen, dient nur dazu, diesen Abstand klein zu halten. Der Aufwand für eine Pipeline lohnt sich nicht wegen der Automatisierung an sich, sondern wegen der Zeit.

2:32 Ein Fehler, den Sie zehn Minuten nach dem Schreiben sehen, kostet Sie einen Gedanken — Sie sind noch im Thema. Derselbe Fehler zwei Wochen später ist eine Fehlersuche mit Archäologie. Genauso wichtig ist die Größe der Änderungen: Wer täglich ausliefert, liefert kleine Pakete aus, und kleine Pakete lassen sich zurückdrehen.

2:50 Und Quality Gates halten schriftlich fest, was gelten muss — sonst entscheidet der Terminkalender darüber, welche Prüfung heute wichtig ist. Diese Tabelle sortiert die drei Begriffe nach einer einzigen Frage: Wer drückt den Knopf. Bauen und Prüfen ist überall automatisch — das ist der gemeinsame Nenner. Der Unterschied liegt rechts. Und der Sprung von der mittleren zur unteren Zeile ist keine technische Entscheidung, auch wenn er oft so verkauft wird.

3:17 Er hängt daran, ob Ihre Tests aussagekräftig genug sind, dass Sie ihnen ohne menschlichen Blick vertrauen, und ob Sie einen erprobten Weg zurück haben. Fehlt eines von beidem, ist die manuelle Freigabe kein Rückstand, sondern eine bewusste Sicherung. Diese vier Muster sehe ich in fast jedem Projekt, das seine Pipeline geerbt hat.

3:36 Der erste ist der häufigste: Continuous Delivery steht in der Präsentation, aber das Ausrollen braucht weiterhin ein Handbuch und eine bestimmte Person. Der Nachtlauf ist der zweite — er stört tagsüber niemanden, aber er meldet den Fehler auch erst am nächsten Morgen und macht damit den ganzen Zweck zunichte. Der dritte ist heikel, weil er schleichend passiert: Wenn Quality Gates unter Termindruck übersprungen werden, ist das Gate faktisch abgeschafft.

4:01 Und der vierte ist der gefährlichste, weil ihn niemand bemerkt.

Die Bausteine von GitHub Actions

4:05 Nach den Begriffen jetzt das Werkzeug. GitHub Actions kommt mit erstaunlich wenig Vokabular aus — fünf Wörter genügen, um alles zu beschreiben, was wir in drei Tagen bauen. Sehen wir uns an, welche das sind und wie sie ineinandergreifen. Ein Workflow ist eine YAML-Datei im Repository, die einen automatisierten Prozess beschreibt.

4:26 Darin stecken Jobs, und Jobs laufen standardmäßig gleichzeitig — das überrascht viele, die von älteren Werkzeugen kommen, wo alles in einer Reihe stand. Jeder Job bekommt seinen eigenen Runner, also eine eigene Maschine, und besteht aus Schritten. Ein Schritt ist entweder ein Kommando oder eine fertige Action von jemand anderem.

4:45 Das ist alles. Wenn Ihnen später ein Workflow unübersichtlich vorkommt, liegt es fast nie an fehlenden Sprachmitteln, sondern daran, dass jemand zu viel in einen einzigen Job gepackt hat. Diese Schichtung erklärt, warum bestimmte Dinge gehen und andere nicht. Weil ein Job auf genau einer Maschine läuft, teilen sich seine Schritte das Dateisystem — aber nicht die Shell.

5:06 Und weil zwei Jobs auf zwei verschiedenen Maschinen laufen, sieht der zweite nichts von dem, was der erste erzeugt hat, solange Sie es nicht ausdrücklich weiterreichen. Genau das ist der Grund, warum wir in Modul vier über Outputs und in Modul sechs über Artefakte sprechen. Merken Sie sich die Grenze zwischen Job und Job — an ihr scheitern die meisten ersten Workflows.

5:27 Die Wahl des Runners ist eine der wenigen Entscheidungen, die Sie am Anfang treffen und später nur mühsam ändern. Von GitHub gehostete Runner sind bei jedem Job frisch — was ein Lauf hinterlässt, findet der nächste nicht mehr vor. Das klingt nach einer Kleinigkeit, ist aber der wichtigste Sicherheitsunterschied überhaupt.

5:45 Eigene Runner geben Ihnen dafür zwei Dinge, die Sie sonst nicht bekommen: Zugang ins interne Netz und freie Wahl der Hardware. Bezahlt wird das mit Pflege, Updates und einer neuen Angriffsfläche. Wir kommen in Modul fünfzehn ausführlich darauf zurück. Der Marketplace ist bequem, und das ist sein Problem. Für Checkout, Sprachumgebung, Cache oder Registry-Anmeldung gibt es fertige Bausteine, und niemand sollte die selbst schreiben.

6:11 Nur: Jede eingebundene Action ist fremder Code, der in Ihrem Job läuft — mit Zugriff auf alles, was der Job hat, einschließlich Ihrer Geheimnisse. Die Auswahl nach Anzahl der Sterne ist deshalb keine Sicherheitsentscheidung. Wir behandeln in Modul dreizehn, wie man fremde Actions bewertet und festnagelt. Für heute genügt: Was Sie einbinden, gehört Ihnen — die Verantwortung wandert nicht mit.

6:35 Der erste Punkt ist der klassische Anfängerfehler mit den besten Absichten: Alles in einen Job, weil es dann übersichtlicher aussieht. Damit verschenken Sie die Parallelität, die GitHub Ihnen geschenkt hätte. Der zweite ist subtiler — die Wartezeit auf einen freien Runner fühlt sich für das Team an wie eine langsame Pipeline, taucht aber in keiner Laufzeitmessung auf.

6:55 Der dritte hat uns die Lieferkettenangriffe der letzten Jahre beschert. Und beim vierten wird ein Workflow zu einem Skript, das lokal niemand nachstellen kann — dann ist die Fehlersuche nur noch Raten mit Wartezeit.

Pipeline-Architekturen und Anti-Patterns

7:07 Bleibt die Frage, wie man diese Bausteine sinnvoll anordnet. Es gibt dafür keine allgemeingültige Vorlage, aber es gibt ein Prinzip, das sich überall bewährt hat — und eine Handvoll Muster, die zuverlässig Ärger machen. Das Prinzip lautet: einmal bauen, überall ausrollen. Der Build erzeugt genau ein Artefakt, alle Prüfungen arbeiten auf diesem Artefakt, und dasselbe Artefakt wandert später in jede Umgebung.

7:31 Der Unterschied zwischen Staging und Produktion steckt dann in der Konfiguration, nicht im Paket. Klingt selbstverständlich — wird aber ständig verletzt, meist aus Bequemlichkeit: Der Deployment-Schritt checkt eben nochmal aus und baut neu. In dem Moment ist das, was Sie geprüft haben, nicht mehr das, was Sie ausliefern. Und alle Prüfergebnisse gelten für ein Paket, das nie beim Kunden ankommt.

7:55 Die Gegenüberstellung macht die Folgen sichtbar. Links wandert ein Artefakt durch alle Stufen, rechts entsteht in jeder Stufe ein neues. Sehen Sie sich vor allem die letzte Zeile an: Ein Rollback bedeutet links, das alte Image wieder auszurollen — das dauert Sekunden. Rechts bedeutet er, den alten Stand neu zu bauen und zu hoffen, dass die Abhängigkeiten von damals noch dieselben sind.

8:18 Genau in dieser Situation will niemand um drei Uhr nachts stehen. Der Herkunftsnachweis, den wir in Modul vierzehn erzeugen, hängt übrigens ebenfalls an dieser Entscheidung: Er beschreibt genau ein Artefakt. Vier Beobachtungen, die alle dieselbe Wurzel haben: Vertrauen. Eine langsame Pipeline führt dazu, dass Prüfungen abgeschaltet statt beschleunigt werden.

8:40 Eine unzuverlässige führt dazu, dass ein rotes Ergebnis als Rauschen gilt — und dann ist auch der echte Fehler nur Rauschen. Eine Pipeline ohne Weg zurück ist eine Einbahnstraße mit Vollgas. Und eine, die einer Person gehört, fällt genau dann aus, wenn diese Person im Urlaub ist. Keines dieser Probleme löst sich durch mehr YAML. Sie lösen sich durch Entscheidungen, die Sie am Anfang treffen.

9:04 Diese vier stehen für die Kategorie Altlast. Die geteilte Testdatenbank ist der Klassiker: Solange nur ein Lauf gleichzeitig stattfindet, geht alles gut — und ab dem Tag, an dem das Team wächst, stören sich die Läufe gegenseitig, scheinbar zufällig. Zugangsdaten im Klartext entstehen fast immer aus einem einmaligen Notfall, der dann bleibt.

9:24 Viele ungepflegte Workflows pro Branch sind ein Zeichen, dass niemand mehr zuständig ist. Und das letzte Beispiel ist keine Übertreibung — Deployment-Schritte an persönlicher Hardware gibt es häufiger, als man denkt.

Übung

9:37 Damit haben wir die Landkarte. Bevor wir die erste Zeile YAML schreiben, sehen wir uns an, wo unser Beispielprojekt gerade steht — denn automatisieren lässt sich nur, was man vorher benennen kann. Unser Beispiel begleitet uns durch alle sechzehn Module: die Beetkarte, eine Anwendung für Schrebergartenvereine mit Parzellen, Gießplänen und Werkzeugausleihe.

9:58 Technisch ein TypeScript-Dienst auf Node.js mit einer PostgreSQL-Datenbank — überschaubar genug, um sie zu durchschauen, und echt genug, um alle Probleme zu haben, die Ihre eigenen Projekte auch haben. In dieser Übung geht es nicht ums Bauen, sondern ums Hinsehen: Was passiert heute von Hand, was löst es aus, und wo verlassen wir uns auf Hoffnung statt auf eine Prüfung.

10:18 Diese Liste ist Ihr Bauplan für die nächsten drei Tage. Der rote Faden dieser vier Schritte ist Ehrlichkeit. Erst alles aufschreiben, was zwischen Commit und Produktion von Hand passiert — auch das, was peinlich ist. Dann je Schritt festhalten, was ihn auslöst und wer ihn ausführt; daraus wird später der Auslöser im Workflow.

10:38 Der dritte Schritt ist der wichtigste: Wo verlassen wir uns heute auf Aufmerksamkeit statt auf eine Prüfung? Und zum Schluss das Branching-Modell, weil es bestimmt, welche Ereignisse es überhaupt zu automatisieren gibt. Nehmen Sie sich dafür Zeit — diese Landkarte begleitet uns bis zum letzten Modul. Bei einer Bestandsaufnahme sind die Fallen menschlich, nicht technisch. Der Ist-Zustand wird beschönigt, weil niemand gern zugibt, dass er freitags noch etwas von Hand nachzieht.

11:06 Die Aufnahme endet beim Build, weil das der bekannte Teil ist — der Weg zum Kunden bleibt vage. Es wird sofort über Werkzeuge gesprochen, bevor überhaupt klar ist, welcher Ablauf abgebildet werden soll. Und Rollback und Fehlerfall fehlen in der Planung ganz, weil sich niemand gern den schlechten Tag vorstellt. Genau diese Punkte klären wir im nächsten Modul mit dem ersten echten Workflow.