Continuous Integration
Developers integrate small changes frequently. Every change is automatically built and validated so integration problems are found close to their source.
Primary goal:Keep the shared codebase healthy.Overviews
CI/CD
CI/CD is a delivery system for moving software changes from source control to reliable user outcomes. It combines frequent integration, automated evidence, reproducible artifacts, controlled deployment, release decisions, observability, and learning.
Core model
CI, delivery, and deployment are related but distinct
Continuous Delivery
The software is kept in a releasable state through automated validation, packaging, environment promotion, and operational readiness.
Primary goal:Make release a safe business decision.Continuous Deployment
Every change that passes the delivery pipeline is automatically deployed to production or a production-facing environment without a manual release gate.
Primary goal:Minimize delay from validated change to production.Pipeline flow
Build evidence progressively
- 01
Commit and review
A change enters version control, receives review, and is associated with a traceable work item.
- 02
Build
Source and dependencies are compiled, bundled, or otherwise transformed into a reproducible artifact.
- 03
Automated verification
Unit, integration, contract, security, quality, and policy checks provide fast evidence.
- 04
Package and publish
An immutable, versioned artifact is stored in an artifact repository or container registry.
- 05
Deploy
The artifact is placed into a target environment using repeatable automation.
- 06
Release
The capability is exposed to users, tenants, regions, or traffic segments.
- 07
Observe and learn
Telemetry, business outcomes, incidents, and user feedback close the loop.
A critical distinction
Delivery is not the same as deployment
Software delivery
The complete capability for turning a change into a validated, releasable outcome. It includes planning, implementation, testing, packaging, security, approvals, deployment, release, verification, and feedback.
Software deployment
The technical act of placing a software version into an environment. A deployment may remain invisible to users until a release decision exposes the capability.
Promotion path
Use environments for distinct kinds of evidence
Local and development environments support rapid feedback; QA and test environments support verification; UAT supports business acceptance; staging rehearses production behavior; production serves real workloads. Preview and sandbox environments support isolated review and experimentation.
Promote the same immutable artifact wherever possible. Change configuration, credentials, and infrastructure bindings by environment rather than rebuilding different binaries.
Safety and governance
Fast delivery needs stronger controls, not fewer controls
Quality gates
Tests, static analysis, security scanning, policy checks, and required approvals.
Environment promotion
Promote the same immutable artifact through development, QA, UAT, staging, and production.
Progressive delivery
Use feature flags, canary releases, blue-green deployment, or phased traffic exposure.
Recovery
Support rollback, roll-forward, database recovery, and fast incident response.
Traceability
Connect commits, builds, artifacts, approvals, deployments, releases, and production evidence.
Secrets and identity
Use scoped machine identities and secret stores rather than embedding credentials.
Performance
Measure flow and stability together
Deployment Frequency
How often changes reach production.
Lead Time for Changes
How long a change takes from commit to production.
Change Failure Rate
The share of changes that cause degradation or require remediation.
Time to Restore Service
How quickly service is restored after a production failure.
Do not optimize one metric in isolation. High frequency with poor recovery is not healthy delivery; low failure rate achieved by releasing rarely may hide excessive batch size and delay.