Deployments und Environments

Deployments und Environments

0:00 Willkommen zum dritten Tag. Wir haben eine Pipeline, die baut, prüft und ein Image veröffentlicht. Heute geht es darum, dieses Image kontrolliert in die Welt zu lassen. Und der zentrale Baustein dafür heißt Environment. Das ist kein Etikett an einem Job, sondern die Stelle, an der die Pipeline anhält und um Erlaubnis fragt — mit eigenen Geheimnissen, eigenen Schutzregeln und einer eigenen Historie.

0:23 In diesem Modul modellieren wir Staging und Produktion, hängen Schutzregeln daran und sprechen über das, was im Ernstfall zählt: den Weg zurück.

Deployments und Environments

0:33 Der dritte Tag behandelt sichere Deployments, Runner und Governance. Wir beginnen mit den Umgebungen und ihren Freigaben, gehen dann zu Geheimnissen, Berechtigungen und der Anmeldung ohne gespeicherte Schlüssel, danach zum sicheren Betrieb und zur Lieferkette. Zum Abschluss Runner-Betrieb und die organisatorische Ebene. Heute wird aus einer Pipeline, die funktioniert, eine, der man Produktionszugriff anvertrauen kann.

Umgebungen modellieren

0:57 Beginnen wir mit dem Behälter. Ein Environment bündelt alles, was zu einer Zielumgebung gehört — und trennt es sauber von allen anderen. Ein Environment ist ein benannter Ort in Ihrem Repository, an dem Geheimnisse, Variablen und Schutzregeln für eine Zielumgebung liegen. Ein Job ordnet sich ihm zu und kann zusätzlich eine Adresse melden, die dann neben dem Deployment erscheint.

1:20 Das Elegante daran: Derselbe Geheimnisname kann in jedem Environment einen anderen Wert haben. Ihr Workflow bleibt also identisch, und trotzdem greift der Staging-Lauf auf andere Zugangsdaten zu als der Produktionslauf. Das ist der Mechanismus, mit dem Sie Umgebungsunterschiede aus dem Artefakt heraushalten — genau wie es Modul acht verlangt.

1:40 Vier Zeilen für die Zuordnung, und der Rest ist gewohnt. Die Adresse ist mehr als Kosmetik: Sie erscheint im Repository neben dem Deployment und beantwortet die Frage, wo dieser Stand eigentlich läuft. Wichtig ist, was Sie hier nicht sehen: Der Zugriff auf das Geheimnis ist an dieser Stelle noch nicht sicher. Er hängt davon ab, ob die Schutzregeln des Environments erfüllt sind — und genau darum geht es im nächsten Kapitel.

2:04 Ein Job kann also an dieser Zeile warten, bevor irgendein Schritt beginnt. Vier Gründe, und der zweite ist der handfesteste. Staging beweist, dass das Artefakt in einer realistischen Umgebung startet, bevor es Nutzer erreicht. Getrennte Geheimnisse verhindern, dass ein Testlauf versehentlich Produktionsdaten anfasst — und das ist keine theoretische Sorge, das passiert regelmäßig.

2:27 Die Freigabe wird an der Umgebung geregelt statt im Workflow diskutiert, was Diskussionen im Pull Request erspart. Und jede Umgebung hat eine eigene Historie, die die einfachste aller Betriebsfragen beantwortet: Was läuft dort gerade? Der erste Punkt ist der häufigste und der gefährlichste: Produktionszugänge liegen als Repository-Geheimnis, und damit kommt jeder Workflow im Repository daran — auch der Testlauf, auch ein neu hinzugefügter.

2:54 Der zweite ist der Klassiker mit den echten Daten im Staging. Der dritte ist eine verpasste Gelegenheit, weil der Umgebungsname fest verdrahtet wird, obwohl der manuelle Auslöser aus Modul drei ihn liefern könnte. Und der vierte ist der stille: ein Environment ohne eine einzige Schutzregel — das ist ein Etikett, kein Schutz.

Schutzregeln und Freigaben

3:13 Jetzt kommt der Teil, der aus dem Etikett ein Tor macht. Und ein Detail dabei ist wichtiger, als es zunächst klingt: Wann genau bekommt ein Job die Geheimnisse zu sehen? Die Antwort steht in der Definition: Ein Job erhält Zugriff auf die Geheimnisse einer Umgebung erst, nachdem alle konfigurierten Regeln erfüllt sind. Das ist der entscheidende Satz dieses Moduls. Der Job wartet also, bevor er überhaupt etwas in die Hände bekommt — nicht mittendrin, nicht danach.

3:40 Damit lässt sich ein Review vor dem Produktionsdeployment technisch erzwingen, nicht nur vereinbaren. Und die Regeln reichen von erforderlichen Prüfenden über eine Wartezeit bis zu erlaubten Branches und eigenen Regeln aus GitHub Apps. Vier Regeln, vier Zwecke. Bei den Prüfenden ist ein Detail wichtig: Sie können bis zu sechs Personen oder Teams eintragen, aber es genügt eine einzige Freigabe.

4:03 Das ist gut so — sonst wäre jeder Urlaub ein Ausfall. Ergänzend lässt sich die Selbstfreigabe unterbinden, was aus der Regel erst eine echte Kontrolle macht. Die Wartezeit ist ein Puffer für den Moment, in dem jemandem der Fehler noch auffällt. Und die Branch-Regel verhindert, dass ein beliebiger Feature-Branch in Produktion liefert.

4:24 Diese Kette ist das Muster, das ich den meisten Teams empfehle. Staging läuft automatisch bei jedem Merge — dort ist Geschwindigkeit gefragt, und ein Fehler kostet nichts. Produktion wartet auf eine Freigabe. Der Unterschied zwischen den beiden mittleren Kästen ist eine bewusste Entscheidung, keine technische Notwendigkeit: Wenn Ihre Tests gut genug sind und der Rollback erprobt ist, dürfen Sie den dritten Kasten weglassen.

4:47 Nur sollte das eine getroffene Entscheidung sein und keine, die sich aus Bequemlichkeit ergibt. Der erste Punkt ist organisatorisch und trotzdem der häufigste Ausfallgrund: eine einzige prüfende Person, keine Vertretung. Der zweite ist der schleichende — Administratoren dürfen die Regeln umgehen, es passiert einmal im Notfall, und dann wird es zur Gewohnheit.

5:08 Der dritte ist eine Selbsttäuschung: Eine Wartezeit ersetzt keine Prüfung, sie verzögert nur. Und der vierte ist die offene Tür, die niemand bemerkt: Sind die erlaubten Branches nicht eingeschränkt, kann jeder Branch in Produktion liefern — und die schöne Freigaberegel gilt dann für einen Weg, den niemand nehmen muss.

Betrieb und Nachvollziehbarkeit

5:26 Bleibt die Frage, die nach jedem Deployment die wichtigste ist — und die man am besten beantwortet, bevor sie sich stellt: Wie komme ich zurück? Jedes Deployment erzeugt ein Objekt mit Umgebung, Status und Adresse. Über Schnittstellen und Webhooks sind diese Ereignisse abrufbar, in der Oberfläche entsteht daraus die Historie: wer wann welchen Stand ausgerollt hat.

5:48 Das klingt nach Buchhaltung und ist im Zwischenfall Gold wert — weil die erste Frage immer lautet, was sich seit gestern geändert hat. Wichtig ist, dass Ihre Workflows den Status auch melden. Sonst steht in der Historie eine Umgebung, die seit drei Wochen angeblich noch ausrollt. Der rote Faden dieser vier Schritte ist Vorbereitung im ruhigen Moment.

6:09 Halten Sie das vorherige Image mit seinem Digest fest, nicht nur mit einem Tag — Tags können verschoben worden sein, der Digest nicht. Bauen Sie einen Workflow, der ein benanntes Image ausrollt. Und dann der Schritt, den fast alle auslassen: Spielen Sie ihn einmal durch, wenn nichts brennt. Ein Rollback, der zum ersten Mal um drei Uhr nachts ausprobiert wird, ist kein Rollback, sondern ein Experiment.

6:32 Und halten Sie fest, welche Datenbankänderungen sich nicht zurückdrehen lassen. Hier kommt die Concurrency Group aus Modul fünf wieder — jetzt mit anderer Einstellung. Zwei gleichzeitige Ausrollungen hinterlassen eine Umgebung in einem Zustand, den keiner der beiden Läufe beschreibt, und die Fehlersuche danach ist mühsam.

6:51 Deshalb wird hier angestellt statt abgebrochen: Wartezeit ist unangenehm, ein halbes Rollout ist schlimmer. Und der letzte Punkt ist der, den man leicht übersieht: Die Gruppe muss alle Workflows umfassen, die diese Umgebung verändern — auch den Rollback-Workflow, den Sie gerade gebaut haben. Der erste Punkt ist der wichtigste des Kapitels: Ein Rollback auf dem Papier ist keiner.

7:13 Der zweite betrifft die Aussagekraft der Historie — sie zeigt Läufe, aber nicht, welcher Stand ausgerollt wurde; das ist der Unterschied zwischen Protokoll und Information. Der dritte ist ein Entwurfsproblem mit echten Folgen: Wenn Migration und Ausrollen in einem Schritt stecken, können Sie beides nur gemeinsam zurücknehmen — und Migrationen lassen sich oft gar nicht zurücknehmen.

7:34 Und der vierte ist die nie gemeldete Statusmeldung.

Übung

7:38 In der Übung bauen Sie beide Umgebungen mit unterschiedlichen Regeln — und gehen einmal den ganzen Weg, inklusive Rückweg. Das Ziel ist eine technisch erzwungene Freigabe, kein Versprechen. Staging bekommt jeden Merge automatisch, Produktion wartet auf eine zweite Person. Und dann der Teil, der die Übung von einer Konfigurationsaufgabe unterscheidet: der erprobte Rollback.

8:01 Achten Sie während des Laufs auf den Hinweis — beobachten Sie den wartenden Job. Er hat zu diesem Zeitpunkt noch keine Geheimnisse. Wer das einmal gesehen hat, versteht den Unterschied zwischen einem Environment und einem selbstgebauten Wenn-Dann im Workflow sofort. Die Reihenfolge ist praktisch gedacht: erst die Umgebungen mit ihren eigenen Geheimnissen, dann die Regeln an der Produktion, dann die Zuordnung im Workflow.

8:26 Schritt vier ist die Concurrency Group — und achten Sie darauf, dass sie anstellt und nicht abbricht; das ist die Umkehrung dessen, was Sie in Modul fünf für den Prüflauf eingerichtet haben. Schritt fünf ist der Durchlauf: auslösen, freigeben, zurückrollen. Nehmen Sie sich für den letzten Teil bewusst Zeit, das ist der wertvollste Teil der Übung.

8:45 Der erste Punkt entwertet die Freigabe: Wenn dieselbe Person freigibt, die den Merge gemacht hat, ist es keine zweite Meinung — deshalb gibt es die Einstellung gegen Selbstfreigabe. Der zweite ist die Tagfalle aus Modul acht, jetzt mit ernsten Folgen: Ein Rollback auf einen verschobenen Tag rollt womöglich genau den kaputten Stand erneut aus.

9:04 Der dritte ist die falsche Einstellung an der Gruppe. Und der vierte macht die ganze Trennung zunichte — ein geteiltes Geheimnis für beide Umgebungen ist ein geteilter Zugang. Im nächsten Modul kümmern wir uns genau darum.