Continuous Delivery (CD) Pipeline Guide 2026: Automate, Optimize, and Deliver with Confidence

Continuous delivery pipelines connect development, testing, and operations into one collaborative process that reduces deployment risk and brings consistency to release cycles. This guide covers what a CD pipeline is, how each phase works, how to build one for your team, and how to measure success with meaningful metrics.

Key takeaways

Here are the main points to keep in mind:

• A continuous delivery pipeline automates the path from code commit to production-ready release, keeping software in a deployable state at all times.
• The four core phases (component, subsystem, system, production) create a repeatable workflow that catches issues early and reduces deployment risk.
• Building a CD pipeline starts small with incremental automation, cross-functional collaboration, and consistent environments.
• Success is measured through both technical key performance indicators (KPIs), including deployment frequency, lead time, and mean time to recovery (MTTR), and organizational outcomes (customer satisfaction, reduced downtime).
• Cultural adoption matters as much as tooling. Teams that treat the pipeline as a feedback loop improve continuously with each release.

Late-night releases and manual deployments feel like ancient history now. Development teams work in shorter, more predictable cycles, integrating new code continuously and delivering updates with confidence that every change has been tested and verified. That rhythm of steady, dependable delivery? The continuous delivery (CD) pipeline powers it.

A CD pipeline is more than a sequence of automated steps. It is a shared workflow connecting development, testing, and operations into one collaborative process. When it works well, teams spend less time managing deployments and more time improving the product itself. CD pipelines bring consistency to release cycles, reduce risk, and help everyone (from engineers to testers to product managers) see exactly where a project stands at any moment.

This guide explores what a continuous delivery pipeline is, how each phase works, how to build one for your team, the benefits and challenges of implementation, and how teams can measure success using clear data and meaningful metrics.

What is a continuous delivery pipeline?

A continuous delivery pipeline is an automated workflow that moves code changes from development through testing and staging until ready for production release.

That single sentence captures the core concept. The practice involves more nuance. A CD pipeline connects every part of the software lifecycle (building, testing, staging, and releasing) into a single, repeatable flow that keeps code in a deployable state at all times. It is automation plus governance, not just a continuous integration (CI) tool or a deploy script.

Think of a CD pipeline as a digital assembly line for software delivery. Just as extract, transform, and load (ETL) pipelines automate how data is extracted, transformed, and loaded, CD pipelines automate how software moves through each stage of release, maintaining consistency, quality, and confidence every step of the way. These automated workflows rely on strong data integration and clear communication so every team can see progress and identify issues early.

A useful way to understand the boundaries: CI ends when code is validated; CD begins when code is packaged for deployment; release management controls when people see it.

Within broader DevOps practices, the CD pipeline serves as the operational backbone that turns collaborative culture into repeatable execution.

{{custom-cta-1}}

Continuous delivery vs continuous integration vs continuous deployment

Continuous delivery pipelines build on the foundation of continuous integration (CI), the practice of merging code frequently and running automated tests to catch issues early. While CI focuses on preserving code quality within the development environment, CD takes the next step: It automates the path from "ready to test" to "ready to deploy."

The terminology gets confusing because "CD" refers to two different practices depending on context. Continuous delivery and continuous deployment share the same abbreviation but differ in one critical way: human approval.

The following table clarifies the distinctions:

When to choose which model

The right approach depends on several factors.

Team maturity often determines the progression. Most teams start with CI, add continuous delivery as testing matures, and consider continuous deployment once they have high confidence in their automated quality gates. Jumping straight to continuous deployment without mature testing? Teams end up pushing broken code to production and lose trust in the entire system.

Regulatory environment plays a significant role. Finance and healthcare organizations often require continuous delivery with explicit approval gates to satisfy audit requirements. A fintech startup might use continuous delivery with manual approval before production due to Service Organization Control 2 (SOC 2) requirements.

Incident tolerance matters too. High-availability systems may prefer delivery over deployment because the manual gate provides an additional checkpoint before changes reach customers. Teams can review deployment timing and coordinate with support staff.

Release frequency goals should align with the model. A software as a service (SaaS) product team aiming to ship 10+ updates daily would find manual approval gates impractical, so continuous deployment makes more sense. A team releasing weekly can comfortably use continuous delivery.

One confusion to address directly: CI is not optional for CD. You cannot deliver continuously without integrating continuously. Deployment is a subset of delivery, not a replacement. Continuous delivery gives teams the confidence that any commit could go to production while preserving the option to decide when. Continuous deployment removes that decision point entirely.

How a continuous delivery pipeline works

A continuous delivery (CD) pipeline brings together a series of connected stages that move code from development through testing and into production. Each stage validates the software in a different way, helping teams identify problems earlier, reduce risk, and deliver changes with greater confidence.

At a high level, a CD pipeline includes four main phases: component, subsystem, system, and production. Each phase builds on the last, combining automation, collaboration, and insight into one unified process.

Component phase

Quality begins here. Individual developers or small teams review, test, and validate their own pieces of code before those components are integrated with the rest of the system. This phase typically completes in three to 10 minutes, enabling fast feedback for developers.

Typical activities at this stage include:

• Code reviews to verify readability and maintainable structure
• Unit tests to confirm that each function behaves as expected
• Static code analysis to identify security flaws or code problems early

Developers use continuous integration tools to trigger automated tests whenever new code is committed. Teams also use data visualization dashboards to track test coverage, code quality scores, and issue trends in real time. By visualizing this data, developers can spot patterns (like recurring test failures or performance slowdowns) and address them quickly before they escalate.

This early phase keeps ownership close to the people writing the code.

Subsystem phase

Once individual components are validated, the next step is to see how they work together. The subsystem phase certifies integrated pieces of functionality in a controlled test environment. This phase typically takes 10-30 minutes, depending on test suite size and infrastructure.

Here, teams focus on:

• Functional testing to verify that the combined components behave correctly, including edge cases, negative scenarios, and accessibility checks
• Performance benchmarking to measure responsiveness and scalability
• Security checks to uncover vulnerabilities or misconfigurations

If functional tests fail, the pipeline aborts. The artifact does not proceed to the system phase.

Because integration testing can surface a wide range of issues, visibility is critical. Teams rely on real-time data dashboards to monitor subsystem performance, test results, and resource usage as they happen. Continuous feedback loops help teams adjust configurations and maintain stability as systems grow more complex.

At this stage, a CD pipeline starts to resemble a feedback engine, automatically surfacing the information required to improve code quality with each iteration.

System phase

The system phase validates the entire assembled product as a whole. Once the subsystems are stable, the team deploys the full application into a staging environment that mirrors production as closely as possible. This environment lets teams simulate conditions before releasing any code for use. System phase can take 30 minutes to several hours, depending on test suite comprehensiveness and whether manual approvals are required.

Testing here is comprehensive and includes:

• Integration tests to verify that all services communicate correctly
• Load and stress tests to measure performance under peak demand
• Security and compliance checks across network layers and interfaces

Where possible, design subsystems to deploy independently rather than assembling them into a monolithic system release. This reduces coordination overhead and allows teams to move at different speeds.

Keeping the staging environment as close as possible to production helps prevent unexpected issues when new code goes live. That is where strong data governance practices come in. Governance keeps configurations, security standards, and data access consistent across every environment. A staging environment that drifts from production configuration is worse than no staging at all. It creates false confidence that tests will pass in production when they will not.

Teams use analytics tools to monitor results and share what they learned in this stage. For example, visualizing response times, memory usage, or error rates helps identify patterns that may not appear in raw logs.

Production phase

The final phase moves validated code into the production environment where people interact with it. This step requires precise and coordinated action to maintain uptime and avoid disruptions. Production deployment typically takes five to 20 minutes for the deployment itself, plus monitoring time for canary validation (often 15-60 minutes).

Common deployment strategies include:

• Blue-green deployments, where two identical environments alternate between active and idle states, allowing instant rollback if issues arise
• Canary releases, which roll out updates gradually to a small subset of teams or customers before expanding to the full audience
• Zero-downtime deployments, using automation to replace old code without service interruptions
• Feature flags, which decouple deployment from release by allowing teams to deploy code without activating it for all people

Many teams also set up manual gates, approval steps that require someone to review before final release. This safeguard is especially useful for industries with strict compliance or audit requirements. Manual approval gates are valuable for compliance but can become bottlenecks if overused. Ensure approvers have technical context and clear criteria to avoid delays.

The concept of release on demand extends beyond deployment mechanics. It means teams can deploy whenever the code is ready, but choose to release based on business timing, customer readiness, or market conditions. This separation of deployment (technical) from release (business) gives organizations flexibility without sacrificing the benefits of continuous delivery.

Throughout this phase, automation handles repetitive tasks, while people focus on oversight and improvement. Integrating data automation into deployment workflows reduces traditional handoffs and helps maintain consistency across environments.

By tracking key performance metrics in real time (such as length of deployment, error rates, and feedback) teams can quickly measure the impact of each release. These metrics become actionable data that guides future decisions and creates the conditions for continuous improvement after each deployment.

Example: A feature flag change flows through the pipeline

To see how these phases connect, consider a developer committing a feature flag toggle to the main branch:

1. The CI server triggers immediately: it builds the artifact and runs unit tests, which pass in three minutes.
2. The pipeline promotes the artifact to the test environment where integration tests run (pass in eight minutes) and a static application security testing (SAST) scan runs (no vulnerabilities found).
3. The artifact moves to staging where load tests verify performance at 500 requests per second. A quality assurance (QA) reviewer must approve the release before proceeding.
4. The reviewer grants approval. The artifact deploys to production via blue-green strategy.
5. Canary release begins: five percent of traffic sees the new flag. Monitoring shows no errors over 30 minutes.
6. Full rollout: 100 percent of traffic now uses the new version, and the feature flag is activated.

At each stage, the pipeline includes decision gates. At staging, the pipeline pauses for manual approval (required for compliance). If load tests fail, the pipeline aborts and notifies the team via Slack.

A continuous, data-driven cycle

A well-designed CD pipeline does not end at production; it loops back into itself. Insights from monitoring and analytics feed directly into planning for the next iteration. When teams can visualize their delivery process from end to end, they gain the ability to identify bottlenecks, adjust priorities, and improve efficiency over time.

For teams, this means fewer late-night release scrambles. Developers, testers, and product leads can focus on delivering value rather than troubleshooting last-minute issues.

Testing strategy: the test pyramid in a CD pipeline

Testing is the backbone of confidence in continuous delivery. Scattered tests across phases don't constitute a strategy. A deliberate approach to test layering, quality gates, and flaky test management separates reliable pipelines from frustrating ones.

Test layers mapped to pipeline phases

Each pipeline phase should run specific types of tests, organized by speed and scope.

Component phase tests form the foundation. Unit tests should comprise roughly 70 percent of your total test suite, running in under five minutes with a code coverage gate of 80 percent or higher. These tests verify individual functions and classes in isolation. That 70 percent ratio matters because unit tests catch the majority of bugs at the lowest cost, both in time and debugging effort.

Subsystem phase tests verify integration. Contract tests for microservices confirm application programming interface (API) contracts between services without requiring full integration tests (tools like Pact help here). Integration tests, roughly 20 percent of your suite, should complete in under 15 minutes and verify that services interact correctly.

System phase tests validate end-to-end behavior. End-to-end tests (roughly 10 percent of your suite) should complete in under 30 minutes and verify critical customer journeys. Load tests verify performance under peak demand and may run up to an hour.

Production phase tests confirm deployment success. Smoke tests should complete in under five minutes and verify that the deployment succeeded and core functionality works.

Quality gate design

Each stage needs explicit pass/fail criteria. Example gates might include:

• Component phase fails if unit test coverage drops below 80 percent or any test fails
• Subsystem phase fails if integration tests fail or SAST finds high-severity vulnerabilities
• System phase fails if load tests show greater than 500ms p95 latency or manual approval is not granted

These gates prevent problematic code from advancing.

Managing flaky tests

Flaky tests (tests that pass or fail inconsistently) erode pipeline trust faster than almost anything else. When developers start ignoring test failures because "that test is always flaky," the entire quality gate system breaks down.

Quarantine flaky tests by moving them to a separate suite. Investigate root causes, which typically include timing issues, environment drift, or race conditions. Either fix the underlying problem or delete the test. Aim for less than two percent flaky test rate. That two percent threshold represents the point where flaky tests start meaningfully degrading developer confidence in the pipeline.

Time budget guidance

Total pipeline runtime goal: under 30 minutes from commit to production-ready artifact (excluding manual approval wait times). Optimize by running tests in parallel and caching dependencies.

Release safety toolkit: progressive delivery, feature flags, and rollback strategies

Deploying to production carries inherent risk. The strategies in this section help teams release confidently while maintaining the ability to recover quickly when something goes wrong.

Canary deployment playbook

Canary releases limit blast radius by exposing changes to a small subset of people first:

1. Deploy the new version to five percent of infrastructure (for example, one pod in a 20-pod cluster)
2. Monitor error rates, latency, and business metrics for 15-30 minutes
3. Configure automated rollback triggers: if error rate exceeds 0.5 percent or p95 latency exceeds 500ms, automatically revert to the previous version
4. If metrics remain healthy, expand to 25 percent, then 50 percent, then 100 percent over one to two hours

Blue-green deployment playbook

Blue-green deployments maintain two identical environments for instant rollback capability:

1. Deploy the new version to the idle "green" environment
2. Run smoke tests on green
3. Switch the router or load balancer to send traffic to green
4. Monitor for 15 minutes
5. If issues arise, switch back to blue (rollback completes in under one minute)
6. Once stable, decommission blue or keep it as a rollback target

Feature flag governance

Feature flags decouple deployment from release. Deploy code with flags off, then turn flags on for specific people or cohorts.

Best practices for feature flag management include using a dedicated feature flag management tool, limiting flag lifespan to avoid technical debt (remove flags after rollout completes), and using flags for canary releases (turn on for five percent of people), A/B tests, and emergency kill switches. Abandoned feature flags accumulate quickly and create maintenance nightmares. Set calendar reminders to clean them up within 30 days of full rollout.

Rollback vs roll-forward

Two recovery strategies exist, each suited to different situations.

Rollback means reverting to the previous version. It's fast but may lose data if the schema changed. Use rollback for infrastructure issues.

Roll-forward means deploying a fix in a new version. It's slower but preserves data. Use roll-forward for data issues.

Database migration safety

Database changes require special care because they can't be rolled back as easily as code.

Use backward-compatible schema changes following the expand/contract pattern: add a new column, migrate data, update code to use the new column, then remove the old column in the next release. Never drop columns or tables in the same release as code changes. Use migration tools like Flyway or Liquibase to version and automate schema changes.

Security and compliance: development, security, and operations (DevSecOps) in the CD pipeline

Security cannot be an afterthought bolted onto the end of the pipeline. Modern CD pipelines integrate security controls at every stage, catching vulnerabilities early when they're cheapest to fix.

Stage-by-stage security controls

Each pipeline phase should include specific security checks.

Component phase security includes SAST (static application security testing, which analyzes source code for vulnerabilities using tools like SonarQube or Checkmarx), secret scanning to detect hardcoded credentials, and dependency scanning/SCA (software composition analysis) to identify vulnerable libraries.

Subsystem phase security includes DAST (dynamic application security testing on the running application) and container image scanning to find vulnerabilities in base images.

System phase security includes infrastructure-as-code (IaC) scanning to check infrastructure-as-code for misconfigurations and compliance checks to verify configurations meet regulatory standards like Center for Internet Security (CIS) benchmarks.

Production phase security includes SBOM generation (creating a software bill of materials listing all dependencies), artifact signing (cryptographically signing build artifacts to verify authenticity), and provenance attestations (recording build metadata per the Supply-chain Levels for Software Artifacts (SLSA) framework to verify supply-chain integrity).

Policy-as-code

Use policy-as-code tools like Open Policy Agent or Kyverno to enforce security policies automatically. Example policies might block deployment if SAST finds high-severity vulnerabilities, require artifact signatures for production deployments, or enforce least-privilege identity and access management (IAM) roles for pipeline service accounts.

Minimal baseline controls

At minimum, every CD pipeline should include SAST in the component phase, SCA in the component phase, DAST in the subsystem phase, and SBOM generation in the production phase.

Store SBOMs and provenance attestations in an artifact repository alongside build artifacts. Retain them for audit trails and incident response.

Pipeline architecture patterns

How you structure your codebase and branching strategy directly affects pipeline design. The choices made here ripple through test layering, release gating, and team coordination.

Branching strategies

Trunk-based development keeps all developers working on a single main branch with short-lived feature branches (typically less than a day). This approach works well with CD because it minimizes merge conflicts and keeps the main branch always deployable. The pipeline runs on every commit to main.

GitFlow uses long-lived branches (develop, release, hotfix) with more formal merge processes. This approach can work with CD but requires more complex pipeline configurations, since different branches may trigger different pipeline stages. Teams using GitFlow often find the branch management overhead conflicts with continuous delivery's emphasis on frequent, small releases.

For most teams adopting CD, trunk-based development with feature flags provides the best balance of safety and velocity.

Repository structure

Monorepo (single repository for multiple services) simplifies dependency management and cross-service changes but requires sophisticated build tooling to avoid rebuilding everything on every commit. Pipeline design must include change detection to run only affected tests.

Polyrepo (separate repository per service) provides clear ownership boundaries and independent release cycles but complicates cross-service changes and dependency versioning. Each repository typically has its own pipeline.

Monolith vs microservices

Monolithic applications have simpler pipeline design. One artifact moves through all stages. Testing is straightforward because everything deploys together.

Microservices require more sophisticated pipeline orchestration. Each service needs its own pipeline, and teams must manage inter-service dependencies. Contract testing becomes essential to verify that services can communicate correctly without requiring full integration environments.

How to build a continuous delivery pipeline

Building a CD pipeline does not require a complete overhaul of your development process. The most successful implementations start small, prove value quickly, and expand incrementally.

Assess your current delivery process

Before automating anything, map out how code currently moves from a developer's machine to production. Identify every handoff, approval step, and manual task along the way. Look for bottlenecks where work queues up waiting for someone's attention, and note which steps introduce the most delays or errors.

Establish baseline metrics for deployment frequency, lead time, and failure rates.

Start with a single service or workflow

Resist the temptation to automate everything at once. Pick one service, application, or workflow that is relatively self-contained and has a clear path to production. This focused approach lets you learn what works, build confidence in the process, and demonstrate results before expanding.

Each small success creates momentum. When stakeholders see faster, more reliable releases for one service, they become advocates for extending the pipeline to others.

Establish consistent environments

Environment inconsistencies cause some of the most frustrating pipeline failures. Code that works perfectly in development breaks in staging or production because of configuration differences, missing dependencies, or version mismatches.

Use infrastructure-as-code tools to define your environments declaratively. This approach ensures that development, testing, staging, and production environments are as identical as possible. When environments are consistent, you can trust that a test passing in staging means it will pass in production.

Integrate automated testing at every stage

Testing is the backbone of confidence in continuous delivery. Structure your tests in layers, with fast unit tests running on every commit, integration tests validating component interactions, and end-to-end tests confirming system behavior.

Shift testing left by catching issues as early as possible in the pipeline. A bug found during unit testing costs far less to fix than one discovered in production.

Tools and technologies for CD pipelines

The CD tooling landscape offers options for every stage of the pipeline. Rather than prescribing specific products, it helps to understand the categories of tools you will need.

The following categories represent the core building blocks:

• CI/CD servers orchestrate the pipeline itself, triggering builds, running tests, and coordinating deployments. Jenkins, GitLab CI/CD, GitHub Actions, CircleCI, and Azure DevOps are common choices. Jenkins, notably, spans both CI and CD, handling everything from code compilation to production deployment.
• Artifact repositories store built packages, container images, and dependencies. Tools like Artifactory, Nexus, and container registries ensure that what you tested is exactly what you deploy.
• Configuration management tools like Ansible, Puppet, and Chef maintain consistent server configurations across environments.
• Container orchestration platforms such as Kubernetes manage containerized applications at scale, handling deployment, scaling, and self-healing.
• Monitoring and observability tools track application health, performance, and errors in production. Prometheus, Grafana, Datadog, and New Relic help teams understand what's happening after deployment.

The best tool choices depend on your existing infrastructure, team expertise, and specific requirements.

Benefits of a continuous delivery pipeline

A continuous delivery (CD) pipeline allows teams to release software more frequently and with greater consistency, reducing delays and easing pressure during release cycles. Automating repetitive tasks and creating predictable workflows frees people to focus on solving complex problems rather than managing deployment details.

Increases reliability and quality

Automated testing and consistent environments mean every change is verified before it reaches the people who rely on it. CD pipelines reduce the risk of regressions and shorten the feedback loop between writing and validating code. Developers can catch issues early, while testers and operations teams can focus on more valuable validation processes instead of repeating manual checks.

Boosts team productivity and collaboration

With a shared delivery process, everyone knows where a change stands and what comes next. Transparency across stages improves how developers, QA, and operations teams communicate. When testing and deployment steps are standardized, teams spend less time troubleshooting and more time building practical improvements.

Enables continuous learning and insight

Each phase of the pipeline generates data (including build times, error rates, and test outcomes) that teams can analyze to find patterns and refine performance. These metrics become data that teams can use to guide decisions and help them improve with each iteration. Many pipelines now include AI data analytics to forecast build stability, predict test failures, and optimize release timing.

According to McKinsey, organizations that redesign their delivery model around near-continuous execution (integrating structured feedback from customer data, incident reports, and usage analytics) are seeing threefold to fivefold improvements in productivity while adapting more quickly to what their customers want. Those productivity gains translate directly into faster feature delivery and reduced time-to-market for CD pipeline adopters.

Challenges in building a continuous delivery pipeline

Building a continuous delivery (CD) pipeline can transform how a team works, but getting there takes time, collaboration, and sustained effort. Even experienced teams run into obstacles when shifting from traditional release cycles to fully automated workflows.

Cultural resistance

The biggest challenge often is not technical. It is cultural. Some teams may hesitate to embrace automation or fear that it limits flexibility. Overcoming this means creating a culture of learning, where experiments are encouraged and mistakes are treated as data, not failure.

Start by demonstrating quick wins with a single service or workflow. When people see tangible improvements in their daily work (fewer late nights, faster feedback, more predictable releases) resistance often transforms into advocacy. Celebrate successes publicly and share metrics that show the pipeline's impact on deployment frequency and failure rates.

Competing priorities

Pipeline work sometimes takes a back seat to feature development, especially when deadlines are tight. But a reliable CD pipeline is infrastructure for new ideas.

Limited resources and skills

Teams may lack the time, tooling, or expertise to build and maintain automation effectively. Successful continuous delivery depends as much on process and collaboration as on technology. Investing in training, shared ownership, and documentation helps keep momentum.

Data and environment inconsistencies

Unclear configurations or poor data management practices can cause tests to pass in staging but fail in production. Establishing strong data governance, consistent environments, and automated checks keeps each phase of the pipeline working as expected.

Continuous delivery succeeds when people, processes, and technology evolve together.

Continuous delivery pipeline best practices

1. Start small and iterate

Instead of automating everything at once, begin with a single service or workflow. Each small success builds trust in the process and makes it easier to expand gradually. Incremental progress creates stability without overwhelming the team.

2. Embed learning into the workflow

Treat the pipeline as a feedback loop, not just a release mechanism. Track build times, failure rates, and deployment frequency to spot trends and improve efficiency. Pair these data points with augmented analytics to identify hidden patterns or recurring issues that human reviews might miss.

3. Standardize environments and processes

Use configuration management and infrastructure-as-code tools to maintain consistency across development, testing, and production environments. It reduces unexpected behavior during deployment and makes troubleshooting less time consuming.

4. Align automation with team goals

Automating processes should simplify work, not add complexity. Revisit scripts, dashboards, and alerts regularly to make sure they support current priorities.

5. Encourage collaboration across roles

Strong CD pipelines grow from shared accountability. Developers, testers, and operations teams should all have visibility into the same data and the same outcomes.

Measuring success in continuous delivery pipelines

Measuring success in continuous delivery (CD) pipelines can be challenging. Each release produces thousands of data points, from build times to recovery rates, and the signal can get lost in the noise. To make sense of it all, teams should look for clear metrics and shared visibility into how well their delivery process is performing.

Technical key performance indicators (KPIs)

Technical KPIs focus on the delivery process itself. The following table organizes the most important metrics:

Organizational key performance indicators (KPIs)

Organizational and departmental KPIs connect delivery outcomes to team and business impact:

• Customer satisfaction and responsiveness to feedback
• Velocity of feature delivery and ability to meet release commitments
• Reduced downtime and improved system availability
• Cross-team collaboration metrics that reflect how well teams coordinate work across environments

Because pipeline data is so detailed, visualizing it in business intelligence dashboards helps teams see patterns across test, staging, and production environments.

Conclusion

A continuous delivery (CD) pipeline brings structure, transparency, and dependability to software releases. It gives teams a clear process for testing, validating, and deploying code so that every change is intentional and understood. By continuously collecting and analyzing data from each stage, teams can see how their delivery process performs and identify exactly where they will have to make improvements.