8. Continuous Integration, Delivery and Deployment

Introduction and Context

Continuous Integration (CI), Continuous Delivery (CD), and Continuous Deployment are practices for converting source-code changes into tested, releasable, and, where appropriate, production-running software. They are central to DevOps because they connect development, testing, security, operations, and business release decisions through an automated and traceable flow.

The three terms describe related but distinct capabilities. Continuous Integration requires developers to merge small changes frequently into a shared repository, where automated compilation, unit testing, static analysis, and other checks provide rapid feedback. Continuous Delivery extends this process so that every change that passes the pipeline is maintained in a production-ready state. Continuous Deployment goes further: approved changes are automatically released to production without a separate manual release action.

These practices do not simply mean purchasing a pipeline tool. They require architectural suitability, reliable tests, versioned configurations, disciplined collaboration, secure credentials, observable environments, and organizational willingness to release in small increments. A technically sophisticated pipeline can still fail if its tests are unreliable, its environments differ from production, or its approval process is unclear.

In earlier discussions of Agile and DevOps, software delivery was presented as a collaborative value stream rather than a sequence of isolated departmental activities. CI/CD operationalizes that idea. It reduces the batch size of change, shortens feedback loops, makes quality visible, and supports evidence-based release decisions. This chapter examines the design of CI/CD pipelines, quality gates, artifacts, environment management, deployment strategies, rollback, governance, and emerging automation.

Learning Objectives

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

1. Distinguish Continuous Integration, Continuous Delivery, and Continuous Deployment.

2. Design a pipeline containing source control, build, test, quality, packaging, promotion, deployment, and verification stages.

3. Explain artifact immutability, versioning, provenance, and promotion across environments.

4. Select appropriate quality gates and deployment strategies for different risk contexts.

5. Design environment-management and configuration practices that reduce deployment inconsistency.

6. Compare rollback, roll-forward, blue-green, canary, rolling, and feature-toggle approaches.

7. Evaluate CI/CD risks involving security, compliance, reliability, cost, and organizational change.

8. Use delivery metrics and an applied scenario to assess pipeline effectiveness.

The Delivery Continuum: Integration, Delivery and Deployment

Continuous Integration

Continuous Integration is a development practice in which changes are integrated into a shared mainline frequently and validated automatically. A typical CI cycle begins when a developer commits code or opens a merge request. The system retrieves the revision, restores dependencies, compiles or packages the application, runs automated tests, and publishes results. The purpose is not merely to confirm that code builds; it is to discover integration defects while the context of the change is still available to the developer.

Effective CI depends on small changes, a buildable main branch, fast feedback, and ownership of failures. A build that remains broken for several days destroys the value of integration because later changes cannot be assessed reliably. Tests should therefore be layered: fast unit tests provide immediate feedback, while more expensive integration or end-to-end tests run later or in parallel.

Continuous Delivery

Continuous Delivery means that the software is automatically built, tested, packaged, and prepared for release so that it can be deployed to production at any time. Deployment to production may still require a business or operational approval. The important property is not that production release happens constantly, but that release is a low-risk, repeatable decision rather than a major technical project.

Continuous Delivery usually involves promotion of the same tested artifact through environments such as development, testing, staging, and production. Rebuilding the application separately for each environment weakens confidence because the production artifact may not be identical to the one tested earlier.

Continuous Deployment

Continuous Deployment automatically releases every change that passes all required checks. It is appropriate when the organization has strong automated testing, observability, reversible changes, suitable architecture, and an acceptable risk profile. It is not a maturity badge that every organization must achieve. A regulated financial transaction system, for example, may use Continuous Delivery with documented approval while still maintaining highly automated technical controls.

The distinction can be summarized as follows:

• CI integrates and validates changes frequently.
• Continuous Delivery keeps validated software releasable.
• Continuous Deployment automatically places validated software into production.

These capabilities form a continuum, but they are not identical. An organization may practice CI without reliable delivery automation, or delivery automation without choosing automatic production deployment.

Anatomy of a CI/CD Pipeline

A pipeline is an executable representation of the path from a change to a running service. Although implementations differ, a robust pipeline commonly includes the following logical stages.

Source and Change Validation

The pipeline starts with a version-control event. Branch protection, code review, commit signing where appropriate, and policy checks establish who changed what and why. A pipeline should record the commit identifier, author, review information, dependency versions, and configuration references. These records support traceability and incident investigation.

Long-lived branches can delay integration and produce difficult merges. Trunk-based development, supported by short-lived branches and feature flags, often reduces this delay. Branching policy should reflect team size, release risk, and product architecture rather than being adopted mechanically.

Build and Dependency Resolution

The build stage compiles source code, resolves dependencies, generates executable packages, and produces machine-readable logs. Reproducible builds are important: the same source revision and declared inputs should generate equivalent outputs. Dependency lockfiles, controlled build images, pinned tool versions, and isolated build agents improve reproducibility.

Build systems should treat dependencies as supply-chain inputs. They must be scanned for known vulnerabilities, license restrictions, malicious packages, and unexpected changes. Caching can make pipelines faster, but caches must be invalidated safely and must not allow untrusted content to contaminate a release.

Automated Testing

Testing is not one activity. Unit tests examine small components in isolation; integration tests examine interaction with databases, queues, APIs, or external services; contract tests verify assumptions between service providers and consumers; system tests assess an assembled application; and acceptance tests evaluate business behavior. Security, performance, accessibility, migration, and resilience tests may also be required.

The test pyramid remains useful as a heuristic: many fast unit tests, fewer integration tests, and a smaller number of expensive end-to-end tests. However, modern distributed systems sometimes require broader contract and environment testing. The design objective is a reliable and economically sustainable feedback system, not adherence to a rigid numerical ratio.

Flaky tests are tests that fail intermittently without a relevant product change. They are especially damaging because teams begin to ignore failures. Flakiness should be measured, quarantined temporarily only under explicit ownership, and removed at its source. A green pipeline that suppresses meaningful failures is not a quality achievement.

Quality and Security Gates

A quality gate is a condition that must be satisfied before the pipeline can proceed. Gates may include compilation success, test thresholds, static-analysis findings, dependency risk, secret detection, infrastructure-policy compliance, container-image scanning, performance limits, or manual approval.

Gates should be risk-based. Blocking every low-severity warning can create noise, while permitting critical vulnerabilities undermines governance. Thresholds must be explicit, version controlled, and reviewed. A useful gate answers three questions: what evidence is required, who owns the decision, and what happens when the gate fails?

Security should be integrated throughout the pipeline rather than postponed to a final audit. Secrets must be retrieved from managed secret stores and must not be embedded in source code or logs. Build agents should have minimum privileges, and pipeline definitions should be reviewed as production code because a compromised pipeline can modify software, infrastructure, and deployment decisions.

Packaging and Artifact Publication

A successful build produces an artifact: for example, a package, container image, mobile application bundle, or infrastructure module. The artifact should have a unique version, checksum, metadata, and provenance linking it to source, tools, dependencies, tests, and approvals.

Artifact immutability means that once an artifact is published, its contents do not change. If a defect is found, a new version is created. Mutable tags such as `latest` can be convenient for experimentation but are unsafe as the sole production reference. Registries should support access control, retention policies, replication, scanning, and audit records.

Promotion and Deployment

Promotion means moving the same artifact to a later environment after it satisfies the relevant controls. Environment-specific values, such as database endpoints or feature settings, should normally be supplied through configuration rather than by rebuilding the artifact. Promotion may be automatic between lower environments and approval-based for production.

Deployment automation should be idempotent: running it more than once should produce the intended state rather than duplicate or corrupt resources. Infrastructure as Code supports this principle by defining infrastructure declaratively and storing its changes in version control. Database changes require particular care because application code and schema versions may coexist during a rolling deployment.

Verification and Feedback

Deployment is not complete when a command succeeds. The pipeline should verify service health through readiness checks, smoke tests, synthetic transactions, logs, metrics, traces, and business indicators. Release verification should distinguish technical health from customer impact. A service can be responding successfully while processing orders incorrectly or producing unacceptable latency.

Automated monitoring can pause a rollout or initiate rollback when error rate, latency, saturation, or domain-specific failure indicators exceed defined thresholds. These thresholds should account for normal variability to avoid both missed incidents and unnecessary reversals.

Environments and Configuration Management

An environment is a controlled context in which software runs. Development environments support rapid experimentation; test environments support verification; staging attempts to approximate production; and production serves users. The closer an environment is to production in operating system, runtime, network, identity, data shape, and deployment mechanism, the more credible its results are likely to be.

Perfect parity is expensive and sometimes impossible, so teams should identify which differences matter. A local workstation may use a lightweight database, whereas production uses a managed cluster. The risk lies not in every difference but in unexamined differences that affect behavior.

Configuration should be externalized, versioned, validated, and separated from secrets. Configuration drift occurs when environments evolve manually and no longer correspond to their declared definitions. Infrastructure as Code, environment templates, policy checks, and periodic reconciliation reduce drift. Test data must be representative enough to reveal defects but anonymized or synthetic enough to protect privacy.

Ephemeral environments, created for a branch or pull request and destroyed afterward, can improve feedback and reduce contention. Their costs, data dependencies, startup time, and security boundaries must nevertheless be managed.

Deployment Strategies and Rollback Design

Deployment strategy is a risk decision, not merely a technical preference.

Rolling Deployment

A rolling deployment replaces instances gradually. Some instances run the old version while others run the new version. It uses resources efficiently but requires backward compatibility and careful handling of mixed-version traffic.

Blue-Green Deployment

Blue-green deployment maintains two production-like environments. Traffic is directed to the active environment, while the other is updated and tested. Switching traffic can be rapid, and rollback is often straightforward. The approach may require additional infrastructure and careful management of stateful data.

Canary Deployment

A canary release sends a small proportion of traffic to the new version. Metrics from the canary are compared with the baseline before exposure increases. Canary analysis may be based on error rates, latency, conversion, geographic segments, or customer cohorts. It requires reliable routing and sufficiently sensitive observability.

Feature Toggles

Feature toggles separate code deployment from feature release. Code can be deployed while a feature remains disabled, or enabled for selected users. Toggles support experimentation and rapid mitigation, but they create operational complexity and should have owners, expiry dates, and cleanup plans.

Rollback and Roll-Forward

Rollback returns the service to a previous version. It is effective when the previous artifact remains compatible with the current environment and data. Roll-forward deploys a corrective version and may be safer when database changes or irreversible external effects make reversal difficult.

A rollback plan should specify detection signals, decision authority, automation, maximum recovery time, data implications, communication, and post-incident review. Database migrations should generally be backward compatible: expand the schema, deploy compatible application code, migrate or backfill data, and contract obsolete fields later. This pattern reduces the risk that rollback leaves code and schema incompatible.

A Framework for Pipeline Design

Pipeline design can be guided by five questions.

First, what is the unit of change? A monolithic application, service, infrastructure module, and database migration may require different validation and release boundaries. Second, what evidence is needed before promotion? Evidence should reflect customer, security, reliability, and regulatory risk. Third, which actions can be automated safely? Repetitive, deterministic, and reversible actions are strong candidates. Fourth, where should human judgment remain? Product approval, risk acceptance, and exceptional release decisions may require accountable people. Fifth, how will failure be detected and contained?

A mature pipeline is usually fast enough to support frequent work, reliable enough to be trusted, secure enough to protect the supply chain, observable enough to explain outcomes, and flexible enough to support different release risks. Pipeline stages should be parallelized where dependencies permit, but optimization must not obscure causal information or weaken controls.

Delivery Metrics and Managerial Interpretation

The four widely used DORA delivery measures are deployment frequency, lead time for changes, change failure rate, and time to restore service. They should be interpreted together. Increasing deployment frequency while change failure rate rises is not necessarily progress. Metrics are useful for identifying system constraints, not for ranking individuals.

Additional measures include pipeline duration, queue time, test flakiness, deployment rollback rate, mean time to detect, approval waiting time, environment utilization, and escaped-defect rate. A manager should ask whether a bottleneck reflects technology, process, architecture, policy, or organizational dependency. For example, a long pipeline may be caused by slow tests, scarce runners, sequential approvals, or unstable test data; each requires a different intervention.

Applied Case: Northstar Payments Platform

Background

Northstar is an illustrative mid-sized payments company operating a web platform and a set of transaction services. Its development teams release approximately once every six weeks. Releases require a weekend deployment involving developers, testers, database administrators, and operations staff.

Situation and Problem

The organization experiences late integration defects, manual configuration errors, and prolonged release windows. A previous release caused elevated transaction failures after a database migration. Although the application was restored, teams disagreed about the correct rollback procedure. Senior management requests “continuous deployment,” but the engineering group lacks confidence in its tests and monitoring.

Analysis

The problem is not simply a missing automation tool. The current process rebuilds the application for staging and production, so the tested binary is not necessarily the released binary. Several tests depend on shared data and fail intermittently. Production configuration is maintained manually. The database migration is destructive and cannot safely coexist with the previous application version. Monitoring focuses on infrastructure availability rather than payment success rate.

The risk profile also matters. Payments require strong auditability, controlled access, segregation of duties, and careful treatment of customer data. Automatic production release may be inappropriate until technical and governance controls improve.

Approach and Solution

Northstar first adopts trunk-based integration with mandatory review and a protected main branch. Every change produces an immutable versioned container image. The pipeline performs unit, contract, integration, security, dependency, and migration-compatibility tests. Flaky tests are assigned owners and tracked separately rather than silently ignored.

The same image is promoted from test to staging and then to production. Environment configuration is stored as versioned declarations, while secrets are obtained at runtime from a managed secret store. Infrastructure and pipeline definitions are reviewed like application code.

The database team redesigns migrations using an expand-and-contract sequence. A blue-green approach is used for stateless services, while transaction traffic initially receives a small canary percentage. Automated verification checks payment success rate, latency, duplicate transactions, and error codes. Production promotion requires an accountable approval supported by pipeline evidence; the technical process is Continuous Delivery rather than Continuous Deployment.

A rollback runbook identifies the release owner, thresholds for stopping the rollout, traffic-switch procedure, data reconciliation steps, customer communication, and escalation contacts. A controlled game day exercises the procedure before a high-volume release.

Outcome

The release process becomes more frequent and less disruptive. The organization can identify the exact artifact, source revision, test evidence, and approver associated with a production change. Some releases are still held for approval, but the approval is evidence-based rather than a manual re-performance of technical steps. Northstar postpones automatic deployment for payment logic while using automatic deployment for lower-risk internal services.

Learning Points

The case demonstrates that CI/CD maturity is multidimensional. Immutable artifacts, reliable tests, environment control, observability, compatible data changes, and governance are mutually reinforcing. A demand for full Continuous Deployment should not override risk analysis. Automation should reduce operational variation while preserving accountability.

Challenges, Risks and Common Mistakes

A common mistake is treating pipeline success as proof of product quality. Tests may omit important behavior, use unrealistic data, or pass while external dependencies fail. Another is optimizing for speed by removing meaningful controls rather than improving test design and execution capacity.

Other risks include excessive pipeline permissions, exposed secrets, compromised dependencies, unreviewed pipeline changes, mutable artifacts, environment drift, inadequate rollback, and excessive reliance on manual production access. Organizations may also create approval bottlenecks that turn automation into a waiting room. Manual approval is valuable when it represents accountable risk judgment; it is wasteful when it merely repeats an already automated check.

Cost is another consideration. Parallel runners, duplicated environments, observability platforms, artifact storage, and ephemeral resources can become expensive. Cost controls should include retention policies, resource quotas, scheduling, and measurement of pipeline value.

Cultural resistance can arise when teams interpret automated evidence as surveillance or fear that frequent releases increase personal blame. Leadership must establish blameless incident learning, shared ownership, and realistic service expectations. A pipeline is a socio-technical system, not an isolated engineering script.

Governance, Ethics and Professional Responsibility

CI/CD systems control the distribution of software and therefore require governance. Access should follow least privilege, with separate roles for code contribution, pipeline modification, artifact publication, and production approval where risk warrants. Audit records should be tamper-resistant and retained according to organizational and regulatory requirements.

Privacy must be considered when production data is copied into test environments. Data masking, synthetic data, retention limits, and access controls reduce exposure. Automated decisions affecting customers should be explainable enough for incident analysis and compliant with applicable law and organizational policy.

Supply-chain security includes dependency provenance, signed artifacts where appropriate, trusted build environments, vulnerability response, and verification of deployment inputs. Compliance should be embedded as executable policy where possible, but automation does not eliminate professional judgment. Teams remain responsible for understanding what their controls measure and what they leave untested.

Technology, AI and Emerging Developments

Modern pipeline platforms increasingly provide reusable workflow templates, policy-as-code, container orchestration, environment provisioning, and software supply-chain attestations. GitOps extends the version-control model to operational state: a declared configuration is reconciled automatically with the running environment. This can improve auditability but requires careful control of repository access and reconciliation behavior.

Artificial intelligence is being used to generate test cases, summarize failures, identify anomalous deployment metrics, suggest pipeline optimizations, and assist with code review. These uses can improve productivity, but generated tests may be superficial, AI recommendations may reproduce bias or miss domain constraints, and sensitive source code may be exposed to external services. Human review, data governance, and measurable validation remain necessary.

Progressive delivery combines feature flags, canaries, automated metric analysis, and staged exposure. Software supply-chain frameworks increasingly emphasize provenance and verifiable build processes. Platform engineering teams are also creating internal delivery platforms that provide approved pipeline capabilities as self-service products. The challenge is to provide useful standardization without preventing teams from adapting controls to their risk context.

Best Practices for Professional Implementation

A sound implementation generally follows these principles:

• Keep changes small and integrate them frequently.
• Build once and promote an immutable artifact.
• Version pipeline, infrastructure, configuration, and policy definitions.
• Make tests fast, deterministic, representative, and owned.
• Treat security and compliance as continuous controls.
• Use least privilege for agents, registries, and deployment identities.
• Externalize configuration and manage secrets separately.
• Design deployments for observability and reversibility.
• Prefer backward-compatible database changes.
• Select rollout strategies according to risk and architecture.
• Measure delivery performance without using metrics to punish individuals.
• Practice rollback and recovery before a real incident.
• Review pipeline failures and improve the system rather than normalizing repeated workarounds.

Chapter Summary

Continuous Integration validates frequent changes in a shared codebase. Continuous Delivery keeps validated software ready for release, while Continuous Deployment automatically releases qualifying changes to production. A complete pipeline links source control, reproducible builds, layered testing, security and quality gates, immutable artifacts, environment promotion, deployment, verification, and feedback.

Effective CI/CD depends on more than automation. Environment consistency, configuration management, artifact provenance, observability, compatible database evolution, governance, and a credible rollback strategy are essential. Rolling, blue-green, canary, and feature-toggle methods provide different balances of speed, resource use, exposure, and reversibility. Delivery metrics help leaders identify constraints when interpreted as measures of the system rather than individual performance.

The central professional principle is risk-adjusted automation. Teams should automate repeatable technical work, preserve accountable judgment where necessary, and design every release so that failure can be detected, contained, explained, and recovered from.

Key Terms

Continuous Integration: Frequent integration of code changes with automated validation.

Continuous Delivery: A capability in which software is always maintained in a production-ready state.

Continuous Deployment: Automatic release of validated changes to production.

Pipeline: An automated sequence that transforms a code change into a tested and deployed result.

Quality Gate: A condition that must be satisfied before a pipeline proceeds.

Artifact: A packaged output of a build, such as a binary, image, or deployment bundle.

Artifact Immutability: The principle that a published artifact is not modified after publication.

Artifact Promotion: Moving the same artifact through progressively controlled environments.

Provenance: Traceable information about an artifact’s source, tools, dependencies, and validation.

Environment Drift: Uncontrolled divergence between environments or between declared and actual infrastructure.

Infrastructure as Code: Declarative management of infrastructure through versioned code.

Feature Toggle: A control that separates code deployment from feature activation.

Canary Deployment: Gradual exposure of a new version to a limited share of traffic.

Blue-Green Deployment: Use of two production-like environments to enable controlled traffic switching.

Rollback: Reversion to an earlier application or configuration version.

Roll-Forward: Deployment of a corrective version instead of reverting to an earlier version.

Flaky Test: A test that fails intermittently without a relevant product change.

Trunk-Based Development: Frequent integration into a shared main development line.

Configuration Drift: Unplanned differences in configuration between intended and actual states.

Progressive Delivery: Controlled, measurable expansion of a release to users or infrastructure.

Review Questions

Short Answer Questions

1. Distinguish Continuous Integration from Continuous Delivery.

2. What is an immutable artifact, and why is it valuable?

3. Define a quality gate and give two examples.

4. What problem does a feature toggle address?

5. Why should database migrations be backward compatible during rolling deployments?

Long Answer Questions

1. Explain the major stages of a CI/CD pipeline and the evidence produced at each stage.

2. Compare rolling, blue-green, and canary deployment strategies, including their risks and resource implications.

3. Discuss how environment management, Infrastructure as Code, and configuration control reduce deployment failure.

4. Explain the relationship between testing, observability, rollback, and Continuous Deployment.

5. Analyze the governance and security requirements of a CI/CD pipeline in a regulated organization.

Analytical / Application Questions

1. A team’s pipeline is fast but has frequent flaky tests and production incidents. Diagnose the likely weaknesses and propose a prioritized improvement plan.

2. Design a release approach for a service that changes both application code and a customer transaction database. Explain how you would manage migration, rollout, monitoring, and recovery.

3. An executive asks why the organization has not adopted Continuous Deployment. Using risk, evidence, governance, and architecture, formulate a defensible recommendation.

22. Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes Continuous Delivery from Continuous Deployment?

A. Continuous Delivery integrates code, while Continuous Deployment only runs unit tests.

B. Continuous Delivery keeps software releasable, while Continuous Deployment automatically releases qualifying changes to production.

C. Continuous Delivery requires manual coding, while Continuous Deployment requires no testing.

D. Continuous Delivery applies only to infrastructure, while Continuous Deployment applies only to applications.

Correct Answer: B. Continuous Delivery keeps software releasable, while Continuous Deployment automatically releases qualifying changes to production.

Question 2

Why is promoting the same immutable artifact through environments preferable to rebuilding for each environment?

A. It guarantees that all tests are unnecessary.

B. It ensures that the artifact tested is the artifact released.

C. It eliminates the need for environment configuration.

D. It permits production artifacts to be edited after publication.

Correct Answer: B. It ensures that the artifact tested is the artifact released.

Question 3

A canary deployment is primarily designed to:

A. Expose a new version gradually to a limited amount of traffic.

B. Replace all production instances simultaneously.

C. Avoid monitoring during deployment.

D. Prevent any coexistence of application versions.

Correct Answer: A. Expose a new version gradually to a limited amount of traffic.

Question 4

Which condition most strongly indicates that a quality gate is poorly designed?

A. It uses explicit, version-controlled criteria.

B. It blocks critical security findings.

C. It creates so many low-value failures that teams routinely ignore pipeline results.

D. It assigns ownership for resolving failures.

Correct Answer: C. It creates so many low-value failures that teams routinely ignore pipeline results.

Question 5

What is the main purpose of a feature toggle?

A. To encrypt source code in the repository.

B. To separate deployment of code from activation of a feature.

C. To replace all integration tests.

D. To make artifacts mutable after release.

Correct Answer: B. To separate deployment of code from activation of a feature.

Question 6

Which database migration approach best supports rollback during a rolling deployment?

A. Immediately delete all columns used by the previous version.

B. Use an expand-and-contract sequence with backward-compatible intermediate states.

C. Rebuild the database separately for every application instance.

D. Disable database monitoring during deployment.

Correct Answer: B. Use an expand-and-contract sequence with backward-compatible intermediate states.

Question 7

A pipeline passes, but payment success rate falls after release. What does this most clearly demonstrate?

A. Build success alone does not establish production quality.

B. Infrastructure availability always measures business success.

C. Automated tests should be removed.

D. Rollback is never appropriate.

Correct Answer: A. Build success alone does not establish production quality.

Question 8

Which practice best reduces CI/CD supply-chain risk?

A. Allowing every build agent administrator access to production.

B. Embedding credentials in pipeline scripts.

C. Using controlled dependencies, provenance, least privilege, and artifact verification.

D. Using an unversioned latest artifact tag for every release.

Correct Answer: C. Using controlled dependencies, provenance, least privilege, and artifact verification.

Question 9

Why should delivery metrics such as deployment frequency and change failure rate be interpreted together?

A. A single metric may conceal deterioration in another aspect of delivery performance.

B. Deployment frequency is unrelated to software delivery.

C. Change failure rate measures only developer productivity.

D. Metrics should be used to rank individual employees.

Correct Answer: A. A single metric may conceal deterioration in another aspect of delivery performance.

Question 10

Northstar requires production approval but automates building, testing, artifact promotion, and deployment execution. Which delivery model does this most closely represent?

A. No integration practice

B. Continuous Integration without delivery automation

C. Continuous Delivery

D. Continuous Deployment in all circumstances

Correct Answer: C. Continuous Delivery