Deployment vs Release: Unraveling Modern DevOps Strategies

What Is Deployment and Release

In the pre‑Internet era, software was first released (manufactured, shipped, and made available for sale) and then deployed (installed and configured by end‑users or IT staff). Release meant the software was ready for market, while deployment involved copying the product to media or installing it on machines.

Release: a version is completed, tested, and delivered to customers (e.g., RTM – Release to Manufacturing).

Deployment: the act of installing that version on target environments, which may be unrelated to a specific feature.

In the Internet, SaaS, and mobile‑app era, deployment often *is* the release – the software is pushed to production and becomes instantly visible to users.

Agile DevOps Decoupling

Modern DevOps separates deployment from release, enabling continuous deployment (automated, frequent pushes to production) and release on demand (business decides when a feature becomes visible).

Continuous Deployment: automatically deploy validated changes to production; release can happen later.

Release on Demand: business triggers visibility of already‑deployed features.

Deployment Strategies

Blue‑Green Deployment : two identical production environments (blue and green). New version is deployed to the idle environment, tested, then traffic is switched in seconds. If problems arise, traffic rolls back to the previous environment.

Rolling Deployment : updates a subset of service instances at a time, gradually moving through the cluster until all instances run the new version.

Dark Launch (Black Launch) : the new version is deployed to production but remains invisible to users; it allows performance testing without affecting the user experience.

Canary Release : a small percentage of users receive the new version first; the rollout expands gradually based on feedback and metrics.

Gray Release : extends canary by increasing user cohorts in multiple stages until the whole user base is on the new version.

A/B Testing : compares two (or more) variants of a feature with statistically similar user groups to determine which performs better.

Technical Enablers

Feature Toggles / Feature Flags : code‑level switches that enable or disable functionality at runtime without redeploying. They support dark launch, canary, gray, and A/B testing.

Feature Branches : separate Git branches for each feature; when ready, they are merged into the release branch, allowing isolated development and selective rollout.

Branch by Abstraction : instead of creating physical branches, an abstraction layer is introduced so new and old implementations coexist; the abstraction is gradually switched to the new code.

Facebook Case Studies

Facebook’s web platform uses a trunk‑based development model with a “push‑from‑master” continuous‑delivery pipeline. Hundreds of small changes are built, tested, and pushed to production multiple times per day, first to internal users (dog‑food) and then gradually to larger user percentages.

Mobile apps follow a “1+1” or “2+1” cadence: one week of development, one week of gray‑release and store submission. Facebook Android uses a weekly cycle; iOS originally used a 2‑week cycle but later aligned to a weekly cadence.

Feature toggles (Gatekeeper) power Facebook’s dark‑launch strategy, allowing new backend behavior to be exercised by a subset of users without changing the front‑end UI.

Summary

Deployment and release have evolved from sequential, tightly coupled steps to independent, automated processes. Continuous deployment provides the technical foundation for on‑demand releases, while strategies such as blue‑green, rolling, dark launch, canary, gray, and A/B testing, together with feature toggles and branch techniques, enable safe, frequent, and business‑driven delivery of software.