Jede App geht durch denselben Workflow

Geben Sie jeder App einen GitHub Actions Workflow pro Slot, gefiltert auf ihren eigenen Source-Pfad und ausgelöst durch einen Push auf den Branch dieses Slots. Der Run baut das Image, pusht es in die Registry, verbindet sich mit der Maschine und fährt den Service hoch.

Halten Sie den Compose Tag pro Service gleich dem Tag, den der Workflow pusht, und lassen Sie Runs parallel bauen, aber an einem Lock auf der Box anstehen. Sieben Workflows fahren das Estate dieser Plattform genau so, und dieselbe Form trägt eine App auf einer Cloud VM, auf gemieteter Hardware oder auf einer Maschine, die Ihnen gehört.

Blue und Green ab dem ersten Deploy

Betreiben Sie ab dem ersten Deploy zwei Slots pro App: green aus dem main branch, blue aus dem candidate branch, jeder mit eigenen Hostnamen und eigenem Env File, beide auf einer Maschine, damit der Candidate nichts extra kostet.

Halten Sie das Image slot-agnostisch und geben Sie die Konfiguration beim Container-Start dazu. Die Promotion taggt dann das Image neu, das auf blue getestet wurde, statt es neu zu bauen, und ein Rollback ist auf einem unveränderlichen Tag ein einziger Schritt. Beweisen Sie jedes Release mit drei Fakten: dem Digest auf der Box, der Image ID des laufenden Containers und einem öffentlichen Hostnamen, der antwortet.

Claude Code schreibt die Pipeline und arbeitet in ihr

Claude Code arbeitet als Harness: schreibt den Workflow, den Compose Service und das SQL-Delta, fährt die Review-Lenses und meldet den geprüften Digest, statt Erfolg zu melden. Guard Hooks und ein Approval Gate legen pro Environment fest, was unbeaufsichtigt erlaubt ist.

Agents gehen den Weg der Apps. Ein MCP Server, ein Agent Service oder ein geplanter Worker bekommt einen eigenen Workflow, eigene zwei Slots und dieselben Checks, damit nichts von einem Laptop läuft. Jeder Agent trägt eine eigene Identity unter denselben Access Policies, die schon für menschliche User gelten, und GitHub Copilot coding agent und code review sitzen im selben Repository, für Teams, die sie ohnehin einsetzen.

7 Workflows
einer pro App und Slot, path-gefiltert, im eigenen Estate dieser Plattform
2 Slots
green aus dem main branch, blue aus dem candidate branch
3 Fakten
hält ein bewiesenes Release fest: Digest, Container Image ID und öffentlicher Hostname
25 Stunden
liefen zwei Slots healthy, während sie niemand erreichte

Eine Pipeline, zwei Slots, jedes Release bewiesen

Bauen und ausliefern 4 Schritte
01

Ein GitHub Actions Workflow pro App und Slot

Geben Sie jeder App einen Workflow pro Slot, gefiltert auf den Source-Pfad dieser App und ausgelöst durch einen Push auf den Branch, aus dem der Slot gebaut wird, dazu manueller Dispatch. Sieben davon fahren das Estate dieser Plattform. Claude Code schreibt und pflegt sie im Repository, deshalb wird die Pipeline reviewt wie jeder andere Code.
02

Einmal bauen, in die Registry pushen, auf der Box pullen

Bauen Sie das Image im Workflow, pushen Sie es in die Container Registry, verbinden Sie sich dann mit der Zielmaschine und führen Sie ein compose pull und danach up -d aus. Halten Sie den Image Tag im Compose File gleich dem Tag, den der Workflow pusht, pro Service: Ein Mismatch an dieser Stelle ist der häufigste Fehler in der Pipeline.
03

Den Deploy beweisen statt ihn anzunehmen

Halten Sie am Ende jedes Runs drei Fakten fest: Das Image auf der Box trägt den gerade gepushten Digest, die Image ID des laufenden Containers entspricht der ID dieses Images, und der öffentliche Hostname antwortet. Ein unveränderter Digest gilt als bewusster No-op. Zwei Slots liefen einmal fünfundzwanzig Stunden healthy, während sie niemand erreichte, weil Container Layer, DNS Layer und Edge Layer jeder für sich korrekt waren.
04

Deploys über ein Lock auf der Box serialisieren

Lassen Sie jeden Run parallel bauen und an einem Lock File auf der Zielmaschine anstehen. Eine GitHub Concurrency Group hält pro Gruppe nur einen wartenden Run, deshalb bricht ein Push über mehrere Workflow-Dateien Runs ab, die deployen sollten. Das Lock kennt diese Grenze nicht, und es verhindert, dass gleichzeitige Layer Pulls einander beschädigen.
Blue und Green als Standard 3 Schritte
05

Blue und Green ab dem ersten Deploy

Betreiben Sie ab dem ersten Tag zwei Slots pro App: green gebaut aus dem main branch, blue aus dem candidate branch, jeder mit eigenen Hostnamen und eigenem Env File. Beide Slots teilen sich eine Maschine, deshalb kostet das Candidate Environment keine Zeile auf der Rechnung und niemand lässt es aus. Markieren Sie die Candidate-Hostnamen als noindex.
06

Promoten, indem Sie das getestete Image neu taggen

Halten Sie Images slot-agnostisch: kein Hostname, keine Redirect URI, keine API Base einkompiliert, die Konfiguration kommt beim Container-Start dazu. Die Promotion taggt dann genau das Image neu, das auf blue lief, statt es neu zu bauen, und ein unveränderlicher Tag macht den Rollback zu einem einzigen Schritt. Alles, was sich zwischen den Slots unterscheidet, steht im Env File und nie im Build.
07

Env File pushen, dann den Container neu erstellen

Ändern Sie ein Secret oder einen Connection String, indem Sie das Env File bearbeiten und pushen und den Container danach mit up -d neu erstellen. Ein Restart behält den alten Wert für immer, weil env_file beim Erstellen des Containers bindet. Nehmen Sie einen Hostnamen erst auf, wenn sein DNS-Record auflöst, denn die Zertifikatsvalidierung wartet danach weit länger, als die Korrektur im DNS dauert.
Agents in der Pipeline 2 Schritte
08

Agents gehen durch dieselbe Pipeline wie Apps

Behandeln Sie einen MCP Server, einen Agent Service oder einen geplanten Worker als weitere App im Estate: eigener Workflow, eigene zwei Slots, dieselben Digest-Checks, dasselbe Env File. Nichts läuft von einer privaten Maschine oder einem Cron auf einem Laptop. Ein Tool, das ein Agent aufruft, läuft zuerst auf dem Candidate Slot, bevor es die Version bekommt, auf die sich Menschen verlassen.
09

Claude Code schreibt die Pipeline und arbeitet in ihr

Claude Code arbeitet hier als Harness: schreibt den Workflow, den Compose Service und das Delta-Skript, fährt die Review-Lenses und meldet den Digest, den es geprüft hat. Guard Hooks und ein Approval Gate begrenzen pro Environment, was unbeaufsichtigt erlaubt ist. GitHub Copilot coding agent und Copilot code review sitzen im selben Repository unter denselben Branch-Regeln, für Teams, die sie ohnehin einsetzen.

Häufige Fragen

Was heißt es konkret, ein gelandetes Release zu beweisen?
Drei Checks nacheinander. Der Digest des gerade gepushten Images wird mit dem Image auf der Box verglichen: Damit steht fest, dass der richtige Build dort liegt. Die Image ID des laufenden Containers wird mit diesem Image verglichen: Damit steht fest, dass der laufende Prozess der deployte ist. Der öffentliche Hostname wird aufgerufen und muss antworten. Zwei Slots liefen einmal fünfundzwanzig Stunden healthy, während sie niemand erreichen konnte, weil Container Layer, DNS Layer und Edge Layer jeder für sich korrekt waren.
Heißt blue/green, dass wir ein zweites Environment zahlen?
Beide Slots laufen auf derselben Maschine, mit eigenen Containern, Hostnamen und Env Files. Das Candidate Environment kostet deshalb keine eigene Hosting-Zeile, und die Datenbanken liegen auf einer gemeinsamen Instanz statt auf einem Service pro Projekt. Den Candidate Slot gibt es ab dem ersten Deploy, und genau das hält die Promotion beim Neu-Taggen eines getesteten Images statt bei einem Rebuild, den noch niemand laufen gesehen hat.
Braucht das Azure oder GitHub Copilot?
Weder noch. Die Pipeline geht von GitHub Actions über eine Container Registry auf eine Maschine, die Sie kontrollieren: eine Cloud VM, gemietete Hardware oder Ihr eigener Server. Claude Code schreibt und prüft sie als Harness. GitHub Copilot coding agent und code review passen in dasselbe Repository und unter dieselben Branch-Regeln, für Teams, die dafür ohnehin lizenziert sind, als Ergänzung und nicht als Voraussetzung.
Dürfen Agents unbeaufsichtigt deployen?
Pro Environment, und die Grenze steht schriftlich fest, bevor der erste Run läuft. Read-only-Checks, Builds und Deploys auf den Candidate Slot laufen unbeaufsichtigt; alles, was den Production Slot berührt, geht durch ein Approval Gate, und Guard Hooks setzen die Grenzen durch, statt dass ein Reviewer sie im Kopf behalten muss. Jede Aktion trägt die eigene Identity des Agents, damit der Audit Trail ein Subject benennt und nicht einen geteilten Service Account.
Wie werden Secrets und Connection Strings geändert?
Sie bearbeiten das Env File dieses Slots, pushen es und erstellen den Container neu. Ein Restart behält den alten Wert für immer, weil das Env File beim Erstellen des Containers bindet. Werte stehen im Env File und im Secret Store des Repositories, nie im Image und nie in einer Prozedurdatei: Die nennt die Datei, in der ein Wert liegt, und nicht den Wert selbst.