Continuous Delivery and Deployment

Introduction

Continuous delivery and continuous deployment are practices for moving software changes from source control to users in a controlled, repeatable, and observable way. They extend continuous integration (CI), in which developers frequently integrate code and automated tests. CI answers, “Is the change integrated and technically acceptable?” Continuous delivery and deployment address a further question: “How can an accepted change be released safely and efficiently?”

A release pipeline is the automated workflow that builds, tests, packages, validates, approves, and deploys a software version. A well-designed pipeline reduces manual error, creates an auditable path to production, and makes deployment a routine engineering activity rather than a high-risk event.

This chapter distinguishes continuous delivery from continuous deployment and explains environments, approvals, promotion rules, rollback, deployment strategies, governance, and practical pipeline design.

Learning Objectives

By the end of this chapter, you should be able to:

• distinguish continuous delivery from continuous deployment;
• explain the purpose of development, test, staging, and production environments;
• construct a release pipeline with gates, approvals, promotion rules, and rollback;
• compare rolling, blue-green, canary, and recreate deployment strategies;
• select deployment and rollback approaches appropriate to operational risk; and
• identify governance, security, observability, and ethical considerations in automated release systems.

From Continuous Integration to Release

A typical software flow is:

1. A developer commits code to version control.
2. The CI system compiles or packages the application.
3. Unit, integration, security, and quality tests execute.
4. A versioned artifact is stored in an artifact repository.
5. The same artifact is promoted through controlled environments.
6. Deployment checks and approvals determine whether it may proceed.
7. Monitoring confirms whether the release is healthy.

The phrase “build once, deploy many” is important. The artifact tested in staging should be the artifact deployed to production. Rebuilding separately for each environment can introduce differences and undermine confidence in test results.

A useful distinction is between a build artifact and a release configuration. The artifact may be an immutable container image or package. Environment-specific values—such as database endpoints, feature flags, and credentials—should be supplied securely at deployment time rather than embedded inconsistently in different builds.

Continuous Delivery and Continuous Deployment

Continuous delivery

Continuous delivery means that every change that passes the required automated checks is kept in a deployable state. Release to production may require a deliberate human decision, such as business approval, a change-management review, or a scheduled release window.

Continuous delivery does not mean that every change reaches users automatically. It means that the organization can release reliably whenever it chooses.

Continuous deployment

Continuous deployment extends continuous delivery by automatically releasing every change that passes all required controls into production. No routine manual production approval is required, although an emergency stop or automated safety control should remain available.

These are not competing definitions of quality. Both require reliable automation, traceability, testing, security controls, and operational readiness. Continuous deployment is not simply “faster delivery”; it requires a higher level of confidence in the pipeline and production safeguards.

Release Pipelines and Environment Design

A release pipeline is commonly organized into stages such as:

Figure: A release pipeline promotes one versioned artifact through progressively stronger controls while production monitoring supplies feedback.

Common environments

• Development: supports rapid coding and local or shared developer testing. It may be unstable.
• Integration or test: validates interactions among components and automated test suites.
• Staging or pre-production: resembles production in configuration, scale, and dependencies as closely as practical. It is used for acceptance, performance, and operational verification.
• Production: serves real users and therefore requires the strongest access control, observability, backup, and change discipline.

Environment names vary between organizations. The essential principle is not the number of environments but the purpose and quality of the controls applied in each one. Excessive environments can create delay and configuration drift; too few can leave important risks undiscovered.

Promotion rules

A promotion rule specifies the conditions under which an artifact may move forward. Examples include:

• all mandatory tests pass;
• vulnerability findings are below an agreed severity threshold;
• code review is complete;
• infrastructure policy checks pass;
• test coverage or quality thresholds are met where meaningful;
• deployment health checks remain successful for a defined observation period;
• a required approver from an independent role authorizes release; and
• the artifact is traceable to a commit, build, ticket, and test report.

Rules should be explicit and machine-enforced where possible. A green pipeline is not proof that a system is defect-free; it is evidence that defined checks passed.

Approvals, Gates, and Separation of Duties

A quality gate is an automated condition, while an approval gate requires a human or authorized service decision. Human approval is valuable where business risk, regulatory obligations, data sensitivity, or unusual operational circumstances require judgment. However, approvals should not become ceremonial clicks.

Good approval design identifies:

• what evidence the approver must inspect;
• who is authorized to approve;
• whether the approver must be independent of the implementation;
• how long the approval remains valid;
• what happens when an approval expires; and
• how the decision is recorded for audit.

Separation of duties reduces the risk that one person can introduce and silently authorize a harmful change. It should be balanced with incident response: emergency changes may use a documented break-glass process followed by retrospective review.

Deployment Strategies

Recreate deployment

The existing version is stopped and the new version is started. This is simple but causes downtime and creates a large failure boundary. It is appropriate only when downtime is acceptable or the system is non-critical.

Rolling deployment

Instances are replaced gradually. During the transition, old and new versions may run simultaneously. Rolling deployment reduces disruption and uses resources efficiently, but compatibility between versions is essential. For example, an application using a database must tolerate the schema during the entire transition.

Blue-green deployment

Two production environments are maintained: blue serves users while green receives the new version. After validation, traffic switches to green. The former blue environment can provide a rapid rollback path. The approach is operationally clear but may require duplicate infrastructure and careful handling of stateful services.

Canary deployment

The new version first receives a small proportion of traffic or a selected user group. Metrics are compared with the existing version before exposure increases. Canary releases reduce blast radius but require reliable routing, representative traffic, meaningful success criteria, and sufficient observation time.

Feature flags

Feature flags separate deployment from feature activation. Code may be deployed while a feature remains disabled, or it may be enabled for selected users. Flags support gradual rollout and rapid deactivation, but they create configuration complexity and must be removed when obsolete.

Health Checks, Observability, and Rollback

Deployment is incomplete until the service is shown to be healthy. Relevant signals include:

• Availability: whether requests can be served;
• Latency: how long requests take;
• Error rate: the proportion of failed requests;
• Saturation: how close resources are to their limits;
• business indicators such as successful orders or completed transactions; and
• logs, traces, alerts, and user feedback.

A rollback restores a previously known-good application version or disables the problematic feature. Rollback is not always safe. Database migrations, external side effects, and irreversible data transformations can make application reversal insufficient.

A safer design often uses expand-and-contract database changes:

1. Expand: add backward-compatible schema elements.
2. Deploy code that can use both old and new structures.
3. Migrate data gradually if necessary.
4. Switch reads and writes to the new structure.
5. Contract: remove obsolete elements only after rollback is no longer required.

Rollback criteria should be defined before deployment. For example, an organization may pause a canary if error rate, latency, or a critical business metric breaches an agreed threshold for a specified observation period. Thresholds must be service-specific; arbitrary universal values are unreliable.

Constructing a Practical Pipeline

A certificate-level pipeline can be designed as follows:

1. Source control: require pull requests, peer review, and protected branches.
2. Build: create a reproducible, versioned artifact and record its dependency information.
3. Automated validation: run unit, integration, API, security, and policy checks.
4. Artifact storage: publish the artifact to a controlled repository with access restrictions.
5. Development deployment: deploy automatically for fast feedback.
6. Staging promotion: deploy the same artifact; run acceptance and operational tests.
7. Release decision: apply automated gates and, when required, an approval.
8. Production deployment: use an appropriate strategy such as rolling or canary.
9. Observation: monitor technical and business indicators.
10. Completion or recovery: confirm success, roll back, disable a feature, or open an incident.

A pipeline should fail safely. It should stop promotion when evidence is missing, preserve logs, avoid exposing secrets, and provide a clear recovery path. Pipeline definitions themselves should be version-controlled and reviewed like application code.

Worked Application: Illustrative Online Learning Service

Background

An illustrative online learning provider operates a web service through which students access lessons and submit assessments. The provider wants frequent releases but cannot tolerate prolonged disruption during examination periods.

Problem

The existing process manually copies files to production. It has inconsistent configuration between test and production, no standard rollback procedure, and limited evidence about who approved each release.

Analysis

The service has moderate availability requirements and sensitive student data. The team therefore needs automated testing, restricted production access, audit trails, backward-compatible database changes, and a release strategy that limits exposure.

Approach and solution

The team implements the following pipeline:

• every pull request runs unit tests, integration tests, dependency scanning, and secret detection;
• a container image is built once, assigned an immutable version, and stored in a registry;
• the same image is deployed to a production-like staging environment;
• an acceptance suite tests login, lesson access, and assessment submission;
• production release requires a documented approval during examination periods;
• a canary deployment sends a small, representative share of traffic to the new version;
• automated checks compare error rate, latency, and assessment-submission success with the existing version;
• if criteria remain healthy, traffic increases gradually; otherwise traffic returns to the prior version; and
• database changes follow expand-and-contract sequencing.

Outcome

The organization gains repeatable releases, traceability, and a smaller blast radius. It does not eliminate defects, but it detects problems earlier and makes recovery faster. During low-risk periods, the same controls can support continuous deployment for selected services; examination-related services retain an approval gate.

Learning points

The case demonstrates that delivery maturity is contextual. Automation should be combined with risk-based controls, not treated as an end in itself. A deployment strategy, approval model, and rollback plan must be designed together.

Challenges and Limitations

Continuous delivery can be undermined by flaky tests, slow pipelines, environment drift, fragile external dependencies, inadequate test data, or excessive manual approvals. Continuous deployment adds the risk that a defect can reach users rapidly. Monitoring may also be misleading if it measures infrastructure health while missing business harm.

Automation can reproduce a bad decision at high speed. Teams should therefore maintain clear ownership, incident procedures, access controls, and regular review of pipeline rules. Security scanning is useful but cannot replace threat modeling, secure design, or human investigation of serious findings.

Governance, Ethics, and Security

Release systems often process source code, credentials, personal data, and audit records. Least-privilege access, secret management, encryption, artifact signing, and protected deployment identities are essential. Logs should be tamper-resistant and should avoid recording sensitive values.

Organizations must consider whether an automated release could change decisions affecting users—for example, eligibility, pricing, education, or access to services. Such systems require testing for bias, explainability where appropriate, privacy protection, and a means of human intervention. Regulatory obligations may require documented approvals, segregation of duties, retention of evidence, and controlled emergency changes.

AI-assisted coding and test generation can improve productivity, but generated code must undergo the same review, security testing, licensing checks, and operational validation as human-written code. AI output is not automatically correct or safe.

Contemporary Practices and Best Practices

Modern delivery programs increasingly use platform engineering, infrastructure as code, policy as code, software bills of materials, signed artifacts, progressive delivery, and observability platforms. These practices improve consistency when implemented with clear ownership.

Recommended practices include:

• keep artifacts immutable and promote the same artifact;
• make pipeline controls reproducible and version-controlled;
• prefer automated evidence over informal status claims;
• design database changes for compatibility and recovery;
• define rollback and stop conditions before release;
• use progressive exposure for high-risk changes;
• measure both technical and business outcomes;
• remove obsolete feature flags; and
• review incidents without blame, focusing on system improvement.

Chapter Summary

Continuous delivery keeps every accepted change deployable while retaining a deliberate release decision. Continuous deployment automatically releases accepted changes after all controls pass. Both depend on reliable CI, immutable artifacts, environment consistency, automated tests, explicit promotion rules, secure approvals, and meaningful observability.

Release pipelines should promote one versioned artifact through progressively stronger environments. Rolling, blue-green, canary, recreate, and feature-flag strategies provide different balances of cost, availability, speed, and risk. Rollback must account for databases and irreversible side effects. Governance, security, auditability, and human responsibility remain essential even when deployment is highly automated.

Key Terms

Continuous delivery: Practice of keeping validated software in a deployable state, usually with a deliberate production release decision.

Continuous deployment: Automatic production release of every change that passes required controls.

Release pipeline: Automated workflow that validates, promotes, and deploys software.

Artifact: Versioned package, binary, or container produced by a build.

Promotion: Moving an artifact to a subsequent environment.

Environment: A distinct execution context such as test, staging, or production.

Quality gate: Automated condition that must pass before progression.

Approval gate: Human or authorized service decision required for progression.

Deployment strategy: Method used to introduce a new version to users.

Rolling deployment: Gradual replacement of old instances with new ones.

Blue-green deployment: Traffic switch between two separately operated environments.

Canary deployment: Gradual exposure of a new version to a small audience or traffic share.

Feature flag: Runtime control that enables or disables functionality.

Rollback: Reversion to a known-good version or configuration.

Blast radius: Scope of users or systems affected by a failure.

Observability: Ability to infer system state from metrics, logs, traces, and events.

Immutable artifact: Artifact whose contents do not change after publication.

Expand-and-contract: Database migration pattern supporting compatibility during transition.

Separation of duties: Division of responsibilities to reduce unauthorized or unchecked changes.

Review Questions

Short Answer Questions

1. What is the principal difference between continuous delivery and continuous deployment?
2. Why is “build once, deploy many” recommended?
3. What is a promotion rule? Give two examples.
4. Name two signals that can be used to evaluate production health after deployment.
5. Why can database changes make rollback difficult?

Long Answer Questions

1. Explain how a release pipeline should move an artifact from source control to production.
2. Compare rolling, blue-green, and canary deployments in terms of risk, cost, and operational requirements.
3. Discuss the role of human approvals in an automated delivery pipeline.
4. Explain how expand-and-contract migrations support safer deployment and rollback.
5. Describe the security, governance, and audit controls appropriate for production releases.

Analytical / Application Questions

1. A payment service experiences a sharp increase in failed transactions during a canary release, while infrastructure metrics remain normal. What should the pipeline do, and why?
2. An organization wants continuous deployment but has unreliable tests and no production monitoring. Evaluate whether it is ready and recommend a staged improvement plan.
3. Design a release pipeline for a student-record system containing sensitive data. Specify environments, gates, deployment strategy, approval model, and rollback considerations.

Multiple Choice Questions with Answers

Question 1

Which statement best describes continuous delivery?

A. Every code change is automatically deployed to production without review.

B. Every validated change is maintained in a deployable state, but production release may require a decision.

C. Only infrastructure changes are tested before release.

D. Software is released only at the end of a long development cycle.

Correct Answer: B. Every validated change is maintained in a deployable state, but production release may require a decision.

Question 2

What is the main reason for promoting the same artifact through environments?

A. It guarantees that the software has no defects.

B. It avoids testing and packaging altogether.

C. It reduces differences between what was tested and what is deployed.

D. It eliminates the need for monitoring.

Correct Answer: C. It reduces differences between what was tested and what is deployed.

Question 3

Which deployment strategy sends a small proportion of traffic to a new version before wider release?

A. Recreate

B. Canary

C. Big bang

D. Manual copying

Correct Answer: B. Canary

Question 4

Which item is primarily an automated quality gate?

A. A required manager sign-off

B. A scheduled meeting

C. A passing vulnerability threshold check

D. A release announcement

Correct Answer: C. A passing vulnerability threshold check

Question 5

What is a key advantage of blue-green deployment?

A. It requires no duplicate environment.

B. It provides a relatively fast traffic switch and rollback path.

C. It guarantees database compatibility automatically.

D. It prevents all downtime in every system.

Correct Answer: B. It provides a relatively fast traffic switch and rollback path.

Question 6

Why are feature flags useful in progressive delivery?

A. They separate deployment of code from activation of functionality.

B. They replace all automated tests.

C. They permanently remove the need for configuration management.

D. They make source control unnecessary.

Correct Answer: A. They separate deployment of code from activation of functionality.

Question 7

Which practice best supports safer database rollback?

A. Deleting the old schema immediately after deployment

B. Using expand-and-contract changes that preserve compatibility during transition

C. Rebuilding the database from untested scripts

D. Allowing each environment to use unrelated schemas

Correct Answer: B. Using expand-and-contract changes that preserve compatibility during transition

Question 8

Which combination is most appropriate for judging post-deployment health?

A. Only CPU usage

B. Only the deployment duration

C. Technical indicators and relevant business indicators

D. The number of files in the artifact

Correct Answer: C. Technical indicators and relevant business indicators

Question 9

What is the purpose of separation of duties in release governance?

A. To ensure one person controls every release step

B. To reduce the risk of unchecked or unauthorized changes

C. To prevent emergency response

D. To eliminate audit records

Correct Answer: B. To reduce the risk of unchecked or unauthorized changes

Question 10

Which statement about continuous deployment is correct?

A. It removes the need for monitoring and recovery procedures.

B. It automatically releases changes that pass the required controls.

C. It means developers do not use version control.

D. It always requires a weekly production window.

Correct Answer: B. It automatically releases changes that pass the required controls.