Deployment

Origin & evolution

The word travelled into software from operations, where deploying meant moving a built thing into position. For years deployment and release🚢ReleaseProduct SpecificationA shipped version of the productView reference → were treated as one motion, because they happened together: you copied the new binary onto the box, restarted the process, and users immediately got the new behaviour. The two ideas separated as teams started shipping more often and wanted to stop coupling the technical event to the user-facing one.

Jez Humble and David Farley made the separation rigorous in *Continuous Delivery* (2010), which introduced the deployment pipeline as an automated path from check-in to a release-ready build. Their distinction is precise. Deployment installs a version into an environment. Release exposes that version, or some feature inside it, to users. Once those are different events, you can deploy on Tuesday and release on Thursday, or deploy to all servers and release to two percent of traffic.

That decoupling produced the techniques teams now reach for by name. Blue-green keeps two identical production environments and switches traffic between them, so a bad version can be abandoned by flipping back. Canary releases the new version to a small slice of users first, watches the metrics🔢MetricStrategyA unified metric that measures progress, health, or behaviour across the productView reference →, then widens the rollout. Rolling deployment replaces instances in batches so the service never fully stops. Feature flags🎌Feature FlagEngineeringA feature toggle for controlled rolloutView reference → push the release decision⚖️DecisionStrategyA recorded decision with context, rationale, and consequencesView reference → into runtime configuration, letting code sit deployed and dark until someone turns it on. Google's DORA research programme later made deployment frequency one of its four key delivery metrics, evidence🔎EvidenceValidationData supporting or refuting a hypothesisView reference → that how often you deploy correlates with how well a team performs, because frequent deploys force the small batch sizes that make each change cheap to verify and easy to reverse.

How it works in practice

A payments team has a new fraud-scoring service ready. The pipeline deploys it to all eight production nodes at 09:00 behind a feature flag set to zero percent. Nothing changes for customers; the code is live but dark. At 09:30 they flag it on for internal staff accounts, then for one percent of real traffic. Dashboards🎛️DashboardData & AnalyticsAn analytics dashboardView reference → show latency holding at 40ms and the fraud catch rate ticking up, so over two hours they widen to five, twenty-five, and a hundred percent. A spike in false declines at twenty-five percent would have meant flipping the flag back to zero in seconds, with no rollback, no redeploy, and no incident🚨IncidentDevOps & PlatformA production incidentView reference →. The deployment happened once at 09:00. The release happened gradually across the morning, each widening governed by what the dashboards showed.

Deployment vs. its neighbours

• Release is the user-facing event: the moment a version, or a feature within it, becomes available to people. A deployment can carry zero releases (dark launch) or many (a flag flipped weeks later). Treating them as one is what makes deploys feel risky.
• Service is the long-lived thing being deployed. A single service is deployed hundreds of times over its life; each deployment is one episode in that service's history, not the service itself.
• CI pipeline🚇CI PipelineDevOps & PlatformA CI/CD pipelineView reference → is the machinery that builds and validates a change and then carries out the deployment. The pipeline is the how; the deployment is the discrete event it produces at the end.

In the graph

In the Unified Product Graph, deployment sits in the engineering region as the bridge between built software and the user-facing release. A service⚙️ServiceEngineeringA deployable service or microserviceView reference → connects through service_deployed_as_deploymentServicedeployed asDeploymenthierarchy, recording that a deployment is one materialisation of a service in an environment. The release decoupling shows up as release_strategy_used_by_deploymentRelease Strategyused byDeploymentcross-domain, which names the technique (blue-green, canary, rolling) governing how exposure happens. test_environment_mirrors_deploymentTest EnvironmentmirrorsDeploymentcross-domain captures the discipline of staging that resembles production closely enough to trust. Modelling deployment as its own node, distinct from the release it may or may not trigger, keeps the technical event and the user event queryable on their own terms, which is exactly the separation the practice depends on.