Continuous Delivery and Deployment: Releasable Versus Automatically Released

Continuous delivery and continuous deployment are related but not identical.

Both automate the path from accepted change to a verified release candidate. The difference is whether production release still waits for an explicit decision.

Continuous delivery keeps every accepted change releasable; continuous deployment automatically releases every qualifying change.

Neither practice means skipping testing, safety controls, or observation.

A concrete example: two pipelines

Both pipelines:

1. build one artifact,
2. run tests,
3. scan dependencies,
4. deploy to a test environment,
5. verify critical behavior,
6. and prepare production configuration.

The delivery pipeline waits for an approved release window. The deployment pipeline proceeds automatically when all policy checks pass.

Delivery versus deployment

Delivery creates and validates something that can be released.

Deployment places that artifact into an environment.

Release exposes behavior to users. Feature flags can separate deployment from release.

Clear terms improve incident and product communication.

The deployment pipeline

A mature pipeline defines:

• source revision,
• build,
• artifact identity,
• tests,
• policy checks,
• environment promotion,
• migrations,
• traffic rollout,
• verification,
• and rollback or mitigation.

The pipeline is executable release knowledge.

One immutable artifact

Build once and promote the same artifact.

Environment-specific runtime configuration should be supplied separately. Rebuilding for production can change:

• dependencies,
• compiler output,
• timestamps,
• or embedded settings.

Artifact digests make identity verifiable.

Environment progression

An artifact may move through:

• integration,
• staging,
• canary,
• and production.

Each stage should answer a risk question. A staging environment that differs significantly from production should not be treated as proof of identical behavior.

Avoid gates that add delay without distinct evidence.

Manual approval

A manual gate can represent:

• business timing,
• legal approval,
• coordinated migration,
• high-risk change,
• or customer communication.

It should not be a person clicking "approve" without reviewing evidence. Automate repeatable checks and preserve human judgment for contextual decisions.

Continuous deployment

Automatic production release works best when changes are:

• small,
• independently deployable,
• tested,
• observable,
• backward compatible,
• and easy to mitigate.

The pipeline should stop automatically when evidence violates policy.

Continuous deployment is disciplined automation, not permanent permission to release anything.

Feature flags

Flags let code deploy while behavior remains hidden or limited.

They support:

• employee testing,
• percentage rollout,
• customer opt-in,
• and rapid disablement.

Flags need ownership and removal; otherwise deployed code accumulates many untested state combinations.

Database compatibility

Production may run old and new application versions simultaneously.

Use expand-and-contract changes:

1. add compatible schema,
2. deploy code supporting old and new,
3. migrate data,
4. switch reads or writes,
5. remove old structures later.

An application rollback cannot restore a column already destroyed.

Rollout strategies

Deployment can use:

• rolling replacement,
• blue-green environments,
• canary traffic,
• or regional waves.

The strategy controls exposure and evidence. It must include state, background workers, and external consumers, not only web traffic.

Verification

After deployment, confirm:

• version running,
• health and readiness,
• critical synthetic journeys,
• error rate,
• latency,
• resource use,
• and business outcomes.

"Deployment command succeeded" proves that the tool completed, not that users are healthy.

Rollback

Rollback returns application traffic to a previous artifact when compatibility permits.

It can fail because of:

• irreversible data migration,
• changed message schema,
• external side effect,
• or old code unable to read new data.

Design rollback or forward-fix strategy before release.

Roll forward

Sometimes the safest correction is a new fixed version rather than reverting.

Roll forward fits when:

• data has migrated,
• the issue is small and understood,
• previous code is incompatible,
• or a flag can disable the affected behavior.

Teams need authority and tooling for both choices.

Pipeline as code

Version pipeline definitions alongside application and infrastructure changes.

Review changes to:

• credentials,
• deployment order,
• environment targeting,
• artifact sources,
• and verification.

Pipeline changes can affect production as directly as application code.

Deployment concurrency

Two production deployments should not race without an explicit coordination model.

A pipeline can use environment locks or a deployment queue so one release completes verification before another changes the same environment. Otherwise, the second release can hide the first release's symptoms, consume its rollback target, or apply migrations in an unexpected order.

Emergency fixes need a documented way to supersede queued work safely rather than bypass every control.

Provenance and release records

For every production release, preserve:

• source commit,
• artifact digest,
• dependency and build provenance,
• pipeline run,
• approvals,
• configuration version,
• deployment times,
• and rollout result.

This record lets responders answer exactly what is running and how it arrived there. A version label alone is weak if it can be rebuilt from different inputs.

Separation of duties

Regulated environments may require different people to author and approve a change.

Automation can preserve:

• authenticated approval,
• policy evidence,
• audit history,
• and artifact identity

without returning to manual file transfer and undocumented commands.

Security

Deployment systems need powerful access.

Protect them with:

• short-lived environment roles,
• restricted runners,
• artifact signing,
• provenance,
• approval boundaries,
• and immutable audit logs.

Compromise of the delivery path is a software supply-chain incident.

Measuring delivery

Useful measures include:

• lead time,
• deployment frequency,
• failed-change rate,
• recovery time,
• pipeline duration,
• and rollback frequency.

Interpret them together. Faster release with rising user failure is not improvement.

When not to automate every release

Some changes need controlled timing:

• irreversible financial event,
• coordinated hardware update,
• legal deadline,
• customer training,
• or multi-organization protocol migration.

Continuous delivery still adds value by keeping the technical release process ready and repeatable.

Knowledge check

1. How do continuous delivery and continuous deployment differ?
2. Why separate deployment from release?
3. What problem does expand-and-contract solve?
4. Why does a successful deployment command not prove user health?
5. When can roll forward be safer than rollback?

The one idea to remember

Continuous delivery keeps a verified artifact ready for controlled release; continuous deployment releases qualifying changes automatically. Both depend on immutable artifacts, compatible changes, staged exposure, production verification, secure pipelines, and a tested mitigation path.