Software delivery
The complete capability for turning an idea or change into a validated, releasable outcome. It includes implementation, review, build, verification, packaging, security, approval, deployment, release, and feedback.
Overviews
Release
A release is not merely a deployment command. It is the controlled transition from a validated software change to an outcome available to users. Reliable release systems combine version control, integration, artifacts, environments, governance, rollout, observability, and recovery.
Core language
Delivery, deployment, and release are different decisions
Deployment
The technical act of installing or activating a software version in an environment. A deployed capability may remain hidden behind a feature flag.
Release
The business and operational decision to make a capability available to intended users or consumers.
Source of truth
Version control makes change traceable
A repository records commits, branches, tags, reviews, and integration history. The goal is not merely storage: it is to make every production change attributable, reviewable, reproducible, and recoverable.
Commit
A coherent snapshot with a useful message and traceable intent.
Branch
An independent line of development used to isolate or coordinate work.
Pull request
A review and automation boundary before integration.
Mainline
The shared branch representing the current integrated state.
Prefer small changes, short feedback loops, and automated validation. Large batches increase review difficulty, merge conflicts, lead time, and rollback risk.
Integration model
Choose a branching strategy that matches release needs
Trunk-based development
Integrate small changes frequently into one shared trunk. Short-lived branches and feature flags reduce merge debt and keep the system releasable.
Feature branching
Isolate work on temporary branches. Useful for review and experimentation, but long-lived branches increase divergence and delayed integration risk.
Gitflow
Uses long-lived main and development branches plus feature, release, and hotfix branches. It can support scheduled releases but adds coordination and merge overhead.
Release branches
Stabilize or maintain a specific release line while mainline development continues. Useful when multiple supported versions must coexist.
End-to-end flow
Build confidence progressively
- 01
Plan the change
Clarify scope, risk, dependencies, compatibility, rollout constraints, and evidence required before release.
- 02
Develop and integrate
Use version control, small commits, review, automated checks, and an explicit branching strategy.
- 03
Build once
Produce a versioned, immutable artifact with traceable source, dependencies, and build metadata.
- 04
Verify progressively
Accumulate evidence through tests, static analysis, security checks, environment validation, and release candidates.
- 05
Promote
Move the same artifact through QA, UAT, staging, and production while changing configuration rather than rebuilding.
- 06
Deploy
Place the version into the target environment using repeatable automation and a documented recovery strategy.
- 07
Release
Expose the capability to users, tenants, regions, or traffic segments through a deliberate release decision.
- 08
Observe and learn
Validate technical health and business outcomes, then capture incidents, feedback, and delivery metrics.
Evidence and traceability
A release is a chain of linked artifacts
Commit and tag
Identify the exact source state.
Build artifact
The deployable package, binary, bundle, or image.
Release candidate
A build considered ready unless blocking evidence appears.
Changelog
A structured history of notable changes by version.
Release notes
Audience-specific explanation of changes, impacts, migration steps, and known issues.
Runbook and rollback plan
Operational instructions for execution, verification, and recovery.
Build once and promote the same immutable artifact. Rebuilding for each environment weakens reproducibility because the production artifact may differ from the one that passed validation.
Risk control
Release progressively when blast radius matters
Feature flag
Separate deployment from release by controlling who can access behavior at runtime.
Canary
Send a small portion of production traffic to the new version and expand only when evidence is healthy.
Blue-green
Maintain two production-capable environments and switch traffic between them.
Rolling deployment
Replace instances gradually while maintaining service availability.
Phased rollout
Expand by tenant, cohort, geography, ring, or percentage over time.
Dark launch
Run new code in production without exposing its output to ordinary users.
Progressive delivery requires objective health signals, explicit stop conditions, and automation that can pause or reverse exposure. Otherwise gradual rollout only delays detection.
Failure planning
Every release needs a recovery strategy
Rollback
Restore a previously known-good application or configuration version. It is fast when artifacts are immutable and data changes remain backward compatible.
Roll forward
Deploy a corrective change when reverting is unsafe, data has already migrated, or the defect can be repaired more reliably in place.
Database changes often determine whether rollback is possible. Use backward-compatible migrations and the expand-and-contract pattern: add new structures first, migrate behavior and data, then remove old structures only after compatibility is no longer required.
Coordination
Governance should reduce risk without creating invisible queues
Release gates
Objective checks for quality, security, policy, readiness, and approvals.
Release train
A predictable cadence that coordinates changes across products, teams, or customers.
Change windows
Approved periods that account for staffing, customer impact, dependencies, and operational risk.
Manual approval is most valuable when it evaluates information automation cannot: customer timing, regulatory obligations, coordinated communications, or irreversible business risk. Routine technical evidence should be automated.
Feedback
Measure flow, quality, and outcomes together
| Area | Example measures | What it reveals |
|---|---|---|
| Flow | Lead time, deployment frequency, batch size, queue time | How quickly changes move through the system |
| Stability | Change failure rate, rollback rate, MTTR, incident count | How safely the system changes |
| Pipeline | Build time, test duration, flaky-test rate, gate failure rate | Where delivery feedback is slow or unreliable |
| Release | Adoption, flag exposure, support contacts, error budget impact | Whether the release produced the intended outcome |
| Business | Conversion, activation, retention, revenue, completed transactions | Whether technical delivery created user or business value |
DORA metrics provide a useful system-level view, but they should be interpreted alongside product outcomes and reliability objectives. Faster delivery that degrades customer trust is not improvement.