Deploy

Deployment is the process of releasing software changes to an environment where they become accessible. Most commonly, "deploy" refers to moving code from development into production - making changes available to actual users. But deployment can target any environment: development, staging, testing, or production, each serving different purposes in the software delivery pipeline.

Why it matters

Deployment is where the rubber meets the road. All the planning, designing, coding, and testing lead to this moment: putting changes in front of users. The quality of deployment practices directly affects how quickly teams can deliver value, how reliably systems operate, and how confidently changes can be made.

Poor deployment practices create fear. Teams avoid deploying because it's risky, which means changes batch up, making each deployment larger and riskier. Releases become events requiring weekends and war rooms. This fear slows everything - product iteration suffers because shipping is painful.

Good deployment practices create confidence. When deploying is routine, teams ship smaller changes more frequently. Problems are smaller and easier to diagnose. The ability to deploy quickly becomes a competitive advantage - features reach users faster, bugs get fixed sooner.

The deployment process

Modern deployment typically involves several stages:

Build - Source code is compiled, packaged, and prepared for deployment. This produces artifacts (containers, packages, binaries) that will be deployed.

Test - Automated tests validate that the build works correctly. Unit tests, integration tests, and other checks catch problems before deployment.

Stage - The build deploys to a staging environment that mimics production. This allows final verification in production-like conditions.

Deploy - The build moves to production. This might happen all at once or gradually through techniques like canary releases or blue-green deployment.

Verify - After deployment, monitoring confirms the release is healthy. Automated checks and human observation detect problems quickly.

Rollback (if needed) - If problems appear, the previous version is restored. Good deployment practices make rollback fast and reliable.

Deployment strategies

Different strategies trade off between risk, complexity, and speed:

All-at-once replaces the old version entirely with the new one. Simple but risky - if something's wrong, everyone is affected immediately.

Rolling gradually replaces instances of the old version with the new one. Some users see the old version while others see the new one during the transition. Less risky but more complex.

Blue-green maintains two identical environments. Traffic shifts from one (blue) to the other (green) instantly. Enables quick rollback by shifting traffic back.

Canary deploys to a small subset of users first. If problems appear, only a small group is affected. Confidence builds before expanding to everyone.

Feature flags deploy code to everyone but control access through configuration. Features can be enabled for specific users, percentages, or conditions.

Deployment frequency

How often teams deploy varies dramatically:

Traditional deployments happen monthly, quarterly, or less frequently. Each release is a major event with extensive planning and coordination. This is increasingly seen as a legacy approach.

Continuous delivery maintains code that's always deployable. Teams can deploy at any time, typically doing so weekly or daily. Deployment is routine rather than exceptional.

Continuous deployment automatically deploys every change that passes tests. Multiple deployments per day are common. This requires sophisticated automation and testing.

Higher deployment frequency correlates with better outcomes - faster delivery, fewer incidents, quicker recovery. But frequency depends on context. A consumer web app can deploy continuously; embedded software for medical devices cannot.

Common challenges

Environment inconsistency causes "works on my machine" problems. Code that worked in development fails in production due to different configurations, dependencies, or data.

Deployment fear leads to infrequent, large releases that are riskier than frequent, small ones. Breaking the cycle requires investment in automation and practice.

Manual processes slow deployment and introduce errors. Each manual step is an opportunity for mistakes and a barrier to frequency.

Incomplete rollback means when problems occur, reverting is difficult or impossible. Without reliable rollback, every deployment becomes higher stakes.

Inadequate monitoring delays problem detection. Issues that aren't observed quickly can cause significant damage before anyone notices.

Coordination overhead in complex systems requires multiple teams to deploy in sequence. This creates bottlenecks and slows everyone down.

Deployment and product management

Product managers typically don't deploy code directly, but deployment practices significantly affect product delivery:

Faster deployment enables faster learning. When shipping is easy, experiments can run, hypotheses can be tested, and feedback can be incorporated quickly.

Feature flags separate deployment from release. Code can be deployed but not visible to users, enabling product managers to control when features go live independently of technical readiness.

Deployment risk affects planning. In organizations where deployment is risky, product decisions must account for that risk. Where deployment is routine, decisions can focus on value rather than logistics.

Monitoring provides product insight. The same infrastructure that monitors deployment health can measure feature adoption and user behavior, informing product decisions.

Understanding deployment capabilities helps product managers plan realistically. Asking "how hard is it to ship this?" and "how quickly can we get this to users?" shapes what's feasible and what's fantasy.