Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Deployment

Pattern

A reusable solution you can apply to your work.

Understand This First

  • Environment – every deployment targets a specific environment.
  • Configuration – deployment often involves applying environment-specific configuration.

Context

This is an operational pattern that bridges development and production. Deployment is the act of making a new version of your software available in a target Environment. It is the moment when code stops being something developers look at and becomes something users rely on.

Deployment can be as simple as copying files to a server or as complex as orchestrating rolling updates across a global cluster. The mechanics vary enormously, but the underlying challenge is the same: get the new version running without breaking things for the people who depend on the old version.

In agentic coding, deployment is one of the areas where agents can help the most, by generating deployment scripts, configuring pipelines, and automating repetitive steps. It’s also where mistakes are most consequential.

Problem

You have code that passes tests and works in staging. Now it needs to run in production, where real users depend on it. How do you transition from the old version to the new one reliably, quickly, and with minimal risk of disruption?

Forces

  • You want to deploy frequently to deliver value quickly, but each deployment carries risk.
  • Users expect zero downtime, but swapping running software is inherently disruptive.
  • The deployment process must be repeatable and automated. Manual steps introduce human error.
  • Deployment involves more than code: database migrations, configuration changes, cache invalidation, and dependency updates all need coordination.

Solution

Automate your deployment process end to end. A deployment should be a single command or a single button press, never a wiki page of manual steps. The process should be the same every time, whether you’re deploying at 10 a.m. on Tuesday or 2 a.m. during an incident.

A typical deployment pipeline includes: build the artifact (compiled binary, container image, bundled assets), run automated tests, deploy to a staging environment for final validation, then deploy to production. Each step should be automated and observable.

Choose a deployment strategy appropriate to your system. Common strategies include:

  • Rolling deployment: replace instances one at a time, so some serve the old version while others serve the new.
  • Blue-green deployment: run two identical environments (blue and green), deploy to the inactive one, then switch traffic.
  • Canary deployment: send a small percentage of traffic to the new version and monitor for problems before rolling out fully.

Regardless of strategy, always have a Rollback plan. Know how to return to the previous version before you deploy the new one.

How It Plays Out

A team deploys by SSH-ing into a server, pulling the latest code, running migrations, and restarting the service. One Friday, a developer misses the migration step. The new code crashes because it expects columns that don’t exist. After the incident, the team writes a deployment script that runs migrations, builds the app, and restarts the service in one command. Deployments become boring, which is exactly what you want.

A developer asks an agent to create a deployment pipeline for a static site. The agent generates a GitHub Actions workflow that builds the site on every push to main, runs link checks, and deploys to GitHub Pages. The entire pipeline is defined in a single YAML file tracked in version control. Deployments happen automatically within minutes of merging a pull request.

Tip

The goal of a good deployment process is to make deployment boring. If deployments are stressful events that require heroics, something is wrong with the process, not with the people.

Example Prompt

“Create a deployment script that runs database migrations, builds the app, and restarts the service in one command. It should fail fast if any step errors and print what went wrong.”

Consequences

Automated, repeatable deployments reduce risk and increase deployment frequency. Teams that deploy easily deploy often, which means smaller changes, fewer surprises, and faster feedback. Deployment becomes a non-event rather than a scheduled ceremony.

The cost is the upfront investment in building the pipeline and the ongoing cost of maintaining it. Deployment automation is infrastructure that must be tested, monitored, and updated as the system evolves. Complex deployment strategies (blue-green, canary) require additional infrastructure and tooling.

  • Depends on: Environment — every deployment targets a specific environment.
  • Depends on: Configuration — deployment often involves applying environment-specific configuration.
  • Uses: Migration — database migrations are typically part of the deployment process.
  • Enables: Rollback — a good deployment process includes the ability to revert.
  • Enabled by: Continuous Integration — CI validates code before deployment.
  • Enables: Continuous Delivery — automated deployment is a prerequisite for continuous delivery.