Agentic DevOps

A deploy that only one person remembers how to run breaks the day that person is out. Each app gets its own GitHub Actions workflow per slot, filtered to that app's source path and triggered by a push to the branch the slot builds from, so releasing never depends on a manual command. Claude Code writes and maintains these workflows in the repository, so the pipeline is reviewed like any other code.

Building the release separately for each environment is how a bug shows up in production that never appeared in testing. The workflow builds the image once, pushes it to the registry, then pulls and starts that exact image on the target machine. The tag on the box always matches the tag just pushed, per service, so what runs is what was tested.

A pipeline that only reports success can still leave the wrong version running, or nothing reachable at all. Every run checks three facts before it counts as done: the image on the box carries the digest just pushed, the running container matches that image, and the public hostname answers. Two slots once stayed marked healthy for twenty-five hours while nobody could actually reach them, because no single one of those checks alone would have caught it.

Two releases landing on the same machine at once is how a deploy corrupts itself instead of just failing cleanly. Every run builds in parallel but queues on a lock held on the target machine before it touches anything there, so concurrent releases never collide mid-write. A push that touches several workflows can still cancel a run that was mid-deploy, which is why the lock on the box, not the pipeline alone, protects it.

Testing a release only after it reaches customers is how a bad update becomes an incident instead of a non-event. Each app runs two slots from day one: green serves customers from the main branch, blue carries the candidate from the same day, each with its own hostnames and environment file. Both share one machine, so the candidate costs nothing extra and nobody skips it to save money.

Rebuilding an image to promote it is how the version that goes live ends up differing, even slightly, from the one that was actually tested. Images carry no environment-specific detail baked in, so promotion simply retags the exact image that ran on blue instead of building a new one. An immutable tag then makes rolling back a single step instead of an emergency rebuild.

A restarted container that keeps an old secret is a failure nobody notices until the wrong value gets used somewhere. Changing a secret or a connection string goes through the secrets MCP server, with a human in the loop, and still needs the container recreated afterwards, since a plain restart alone leaves the old value in place. A new hostname is only added once its DNS record resolves, so certificate validation never waits on a problem that was already fixed.

An agent or automation running from someone's laptop is a dependency nobody can see or audit. An MCP server, an agent service or a scheduled worker counts as one more app in the estate: it gets its own workflow, its own two slots and the same release checks as everything else. A tool an agent calls proves itself on the candidate slot before it reaches the version people actually rely on.

A pipeline only one engineer understands is a pipeline that stalls the day that engineer is busy elsewhere. Claude Code works here as the harness: it writes the workflow and the compose service, runs the review checks, and reports the digest it verified rather than simply claiming success, with guard hooks and an approval gate deciding what may run unattended. GitHub Copilot coding agent and code review fit into the same repository, for teams already using them, so matching this to your own pipeline starts with a look at what you deploy today.