Continuous Integration and Continuous Delivery (CI/CD): A Complete Reference

Continuous Integration and Continuous Delivery (CI/CD) form the operational backbone of modern software delivery pipelines, governing how code changes move from a developer's workstation through automated testing and into production environments. This reference covers the structural mechanics, classification boundaries, causal drivers, and known tensions within CI/CD as a professional practice discipline — drawing on published standards from NIST, DORA, and IEEE. The scope applies to commercial, enterprise, and government software delivery contexts within the United States.

• Definition and scope
• Core mechanics or structure
• Causal relationships or drivers
• Classification boundaries
• Tradeoffs and tensions
• Common misconceptions
• Checklist or steps
• Reference table or matrix
• References

Definition and scope

CI/CD designates a two-stage automation discipline within software delivery. Continuous Integration (CI) is the practice of merging developer code branches into a shared repository multiple times per day, with each merge triggering an automated build and test sequence. Continuous Delivery (CD) extends the pipeline to ensure the software artifact produced by CI is always in a deployable state, with releases executed manually or automatically into staging or production environments.

The scope of CI/CD spans the full software development lifecycle, from version control commit through post-deployment monitoring. NIST SP 800-218 (Secure Software Development Framework) identifies automated integration pipelines as a required practice baseline for software organizations operating in or supplying to federal environments. The framework categorizes automated build, test, and release tasks under its "Produce Well-Secured Software" function, placing CI/CD within a formal security compliance context — not merely as a productivity optimization.

The 2023 State of DevOps Report published by DORA (DevOps Research and Assessment) quantifies the operational gap between organizations with mature CI/CD practices and those without: elite performers deploy code 208 times more frequently and restore service 2,604 times faster than low-performing peers. These figures ground CI/CD not as a best-practice aspiration but as a measurable differentiator in software delivery capability.

App Development Authority provides detailed treatment of how CI/CD pipelines are structured within enterprise mobile and web application development, including governance requirements, architectural integration, and the qualification standards that apply to delivery teams operating at scale.

Core mechanics or structure

A CI/CD pipeline is a sequenced, automated workflow composed of discrete stages. Each stage gates the artifact's progress — a failure at any stage halts the pipeline and generates feedback to the committing engineer.

Stage 1 — Source Control Trigger
A commit or pull request to a monitored branch in a version control system (Git being the predominant implementation) initiates the pipeline. Version control systems serve as the single source of truth for pipeline initiation events.

Stage 2 — Build
The pipeline compiles or assembles the application artifact from source. Dependency resolution, compilation, and packaging occur here. Build failures are attributed to source errors or environment mismatches.

Stage 3 — Automated Testing
The artifact passes through layered test suites. Unit tests validate individual functions; integration tests validate component interactions; end-to-end tests validate user-facing behavior. Software testing types and test-driven development practices directly determine the coverage density at this stage.

Stage 4 — Static Analysis and Security Scanning
Static application security testing (SAST) tools scan the codebase for known vulnerability patterns. NIST SP 800-218 designates automated vulnerability scanning as a required activity within the build process for regulated software. Software security engineering principles govern scanner configuration and remediation thresholds.

Stage 5 — Artifact Storage
A passing artifact is versioned and stored in an artifact registry — a binary repository that serves as the deployment source of record.

Stage 6 — Deployment to Staging
The artifact is deployed to a staging environment that mirrors production configuration. Smoke tests and acceptance tests execute against this environment.

Stage 7 — Release Gate
In Continuous Delivery, a human approval action triggers the production deployment. In Continuous Deployment (a distinct variant), no human gate exists and release is fully automated upon staging success.

Stage 8 — Production Deployment
Software deployment strategies — blue-green, canary, rolling — determine how the artifact enters the live environment with controlled risk.

Stage 9 — Monitoring and Feedback
Post-deployment monitoring and observability tooling captures runtime metrics, error rates, and latency. Pipeline feedback loops incorporate production signals into the next development cycle.

Causal relationships or drivers

Three structural forces drive CI/CD adoption within software organizations.

Release frequency pressure. Market conditions in enterprise software — and the competitive dynamics of consumer applications — compress acceptable release cycles. Annual or quarterly releases create integration backlogs that increase defect density. The agile methodology shifted organizational expectations toward sprint-level delivery, which CI/CD pipelines operationalize at the toolchain level.

Integration risk accumulation. Long-lived feature branches that merge infrequently generate "merge debt" — overlapping changes that conflict in unpredictable ways. CI disciplines address this by enforcing daily or sub-daily integration, limiting the time window in which divergence can accumulate. Technical debt frameworks classify deferred integration as a liability that compounds merge cost over time.

Regulatory and compliance pressure. Federal civilian agencies procuring software under FedRAMP and defense contractors under DISA STIGs face mandated pipeline security controls. NIST SP 800-218 imposes automated testing, vulnerability scanning, and integrity verification requirements on software delivery pipelines. Organizations delivering software to these markets must structure CI/CD pipelines to satisfy those controls or accept procurement disqualification.

DevOps practices as an organizational model serve as the cultural and structural precondition for CI/CD adoption — pipeline automation cannot function sustainably without shared ownership, incident accountability, and feedback discipline across development and operations teams.

Classification boundaries

CI/CD terminology is applied inconsistently across the industry. Three distinct terms carry different operational meanings:

Continuous Integration (CI): Covers only the build and test automation triggered by a source control event. No deployment occurs. The output is a tested, validated artifact.

Continuous Delivery (CD — delivery): Extends CI with a deployment pipeline that keeps the artifact in a perpetually releasable state. Production release requires an explicit human approval action. This is the standard CD definition used in enterprise and regulated environments.

Continuous Deployment (CD — deployment): Fully automated release to production without a human gate. Any artifact that passes all pipeline stages deploys automatically. This variant is uncommon in regulated industries due to compliance and audit requirements.

CI/CD Pipeline vs. CI/CD Platform: A pipeline is a specific workflow configuration. A platform is the tooling infrastructure (e.g., Jenkins, GitHub Actions, GitLab CI, AWS CodePipeline) that hosts and executes pipelines. Platform selection is an infrastructure concern; pipeline design is an engineering and process concern.

CI/CD vs. DevOps: DevOps names the organizational and cultural model. CI/CD names the technical practice. DevOps without CI/CD is an organizational aspiration; CI/CD without DevOps cultural structures produces pipeline automation that engineering teams work around. The infrastructure as code discipline provides the provisioning layer that CI/CD pipelines depend on for environment consistency.

The software architecture patterns employed by an application — monolithic, microservices, or event-driven — determine which pipeline topology is appropriate. A monolith typically uses a single pipeline; a microservices architecture requires per-service pipelines with inter-service contract testing.

Tradeoffs and tensions

Pipeline speed vs. test coverage. Comprehensive automated test suites increase confidence but extend pipeline execution time. A pipeline that takes 45 minutes to complete slows feedback loops and discourages frequent commits — undermining the core CI objective. Teams manage this by parallelizing test execution and stratifying tests by execution time.

Security gate strictness vs. delivery velocity. Blocking pipelines on every SAST finding creates false-positive fatigue and motivates engineers to suppress scanner output. Permissive gates allow vulnerabilities to reach production. The tension is managed through severity thresholds — high and critical findings block; medium and low findings generate tickets — a pattern codified in NIST SP 800-218 guidance on integrating automated analysis.

Continuous Deployment vs. governance requirements. Fully automated production releases conflict with change management processes required under frameworks such as ITIL, SOC 2, and FedRAMP. Organizations operating under these frameworks structurally cannot adopt continuous deployment; they implement continuous delivery with documented approval gates instead. The software product management function typically owns the release gate decision.

Environment parity vs. cost. Staging environments that exactly mirror production infrastructure provide reliable pre-release signal. Full parity is expensive. Drift between staging and production configurations introduces a class of defects that CI/CD cannot catch — a known structural limitation of cost-constrained pipeline designs.

Pipeline complexity vs. maintainability. Pipelines accumulate configuration over time. Without deliberate refactoring and ownership assignments, pipeline YAML configurations develop the same accumulation patterns as application code — untested paths, deprecated steps, and undocumented dependencies that create fragility.

Common misconceptions

Misconception: CI/CD eliminates the need for manual testing.
Automated test suites cover deterministic, codified behaviors. Exploratory testing, usability assessment, and adversarial security testing require human judgment. NIST SP 800-218 does not treat automated testing as a substitute for human security review; it treats both as required components of a complete software assurance program.

Misconception: Continuous Delivery and Continuous Deployment are the same.
The distinction is operationally significant. Continuous Delivery requires a human release decision. Continuous Deployment eliminates that gate entirely. Conflating the two leads organizations to implement the wrong model for their governance requirements — particularly in regulated environments where audit trails of release approvals are mandated.

Misconception: CI/CD is a tooling problem.
Platform selection (Jenkins vs. GitHub Actions vs. GitLab CI) is a secondary decision. The primary CI/CD challenges are organizational: test coverage ownership, pipeline failure accountability, environment management, and release governance. Organizations that treat CI/CD as a tool installation project without addressing these structural dimensions produce pipelines that teams bypass. The software engineering roles and career paths that own pipeline maintenance — DevOps engineers, platform engineers, site reliability engineers — are distinct professional categories with defined qualification expectations.

Misconception: A passing pipeline means the software is production-ready.
A pipeline validates against its configured test suite. Coverage gaps, incorrect test assumptions, and environmental mismatches between staging and production all allow defect-bearing artifacts to pass pipeline gates. Pipeline health is a necessary but not sufficient condition for release confidence.

Misconception: CI/CD is only relevant for web applications.
Embedded software engineering and firmware development pipelines incorporate CI principles adapted for hardware-in-the-loop testing environments. The IEEE 12207 software lifecycle standard, which covers all software domains, is agnostic to application type — the integration and verification principles apply across deployment targets.

Checklist or steps

The following sequence describes the structural components present in a conformant CI/CD pipeline, as referenced in NIST SP 800-218 and DORA research baselines. This is a compositional inventory, not a prescriptive implementation guide.

Source Control Configuration
- [ ] All production-bound code resides in a version control system with access controls
- [ ] Branch protection rules prevent direct commits to main/trunk branches
- [ ] Commit signing or verified commit policies are enforced

Build Stage
- [ ] Build process is fully automated and reproducible from a clean environment
- [ ] Dependency versions are pinned and resolved from a trusted registry
- [ ] Build artifacts are versioned with a deterministic naming scheme

Automated Test Stage
- [ ] Unit test suite executes on every commit
- [ ] Integration test suite executes on merge to trunk
- [ ] Code coverage thresholds are enforced as pipeline gates
- [ ] Test results are stored and accessible for audit

Security Analysis Stage
- [ ] SAST tool scans execute on every build
- [ ] Software composition analysis (SCA) scans third-party dependencies
- [ ] High/critical severity findings block pipeline progression
- [ ] Scan results are logged with artifact provenance

Artifact Management
- [ ] Passing artifacts are stored in an immutable artifact registry
- [ ] Artifact integrity is verifiable via checksum or signature
- [ ] Registry access is restricted to pipeline service accounts

Deployment Stage
- [ ] Deployment to staging is automated upon artifact publication
- [ ] Staging environment configuration is managed as infrastructure as code
- [ ] Smoke tests execute automatically post-deployment to staging
- [ ] Production release gate is documented with approval audit trail (Continuous Delivery model)

Post-Deployment
- [ ] Rollback procedure is automated and tested
- [ ] Deployment events are logged to observability platform
- [ ] Pipeline execution metrics (build time, failure rate, MTTR) are tracked against DORA benchmarks

The broader software engineering reference index situates CI/CD within the full landscape of engineering disciplines, tooling categories, and professional practice areas that intersect with pipeline design and delivery automation.

Reference table or matrix

CI/CD Implementation Patterns by Organizational Context

DORA Four Key Metrics — CI/CD Performance Benchmarks

Source: 2023 State of DevOps Report, DORA

References

• NIST SP 800-218: Secure Software Development Framework (SSDF) — National Institute of Standards and Technology
• DORA 2023 State of DevOps Report — DevOps Research and Assessment
• IEEE Std 12207: Systems and Software Engineering — Software Life Cycle Processes — IEEE / ISO/IEC
• NIST SP 800-53 Rev 5: Security and Privacy Controls for Information Systems — National Institute of Standards and Technology
• FedRAMP Authorization Framework — General Services Administration
• DISA Security Technical Implementation Guides (STIGs) — Defense Information Systems Agency