What Is Continuous delivery in DevOps?

Think of continuous delivery like a high-quality bakery that prepares fresh batches of bread every hour. The bakers mix the dough, let it rise, shape it, and bake it. Each batch is checked for quality and then kept warm, ready to be brought out to the display case at a moment's notice.

The bread is always fresh, always ready, and the bakery never has to start from scratch when a customer walks in. In the same way, continuous delivery means that every time a software developer makes a change to the code, that change goes through an automatic pipeline that builds it, runs tests, checks for errors, and then stores it in a deployable state. The code is always ready to be sent to users.

The team does not have to do a big, stressful manual process to prepare a release. Instead, they can decide to release the latest version at any time, often multiple times a day. This reduces risk because changes are small and tested thoroughly.

It also lets teams get feedback from users faster and fix problems quickly. Continuous delivery does not mean every change is automatically released to users. That is called continuous deployment.

In continuous delivery, the final step of actually releasing to production is still a manual decision. But the code is always in a release-ready state, so that decision can be made quickly and safely. This practice relies heavily on automation, a reliable testing suite, and a well-defined pipeline that ensures every change meets quality standards before it can be considered ready for production.

Continuous delivery (CD) is a software development practice that extends continuous integration (CI) by automating the entire release process up to the point of production deployment. In a continuous delivery pipeline, every code commit that passes all automated tests is automatically built, packaged, and deployed to a staging or pre-production environment that mirrors production. The key distinction from continuous deployment is that the final promotion to the live production environment requires a manual approval gate, though the artifact is always in a deployable state.

The pipeline typically includes stages such as source code checkout, compilation, unit testing (often using frameworks like xUnit or NUnit for .NET or pytest for Python), static code analysis (e.g.

, SonarQube), integration testing, security scanning (SAST/DAST), artifact creation (e.g., Docker images, NuGet packages, or JAR files), and deployment to a staging environment. After successful validation in staging, a release candidate is stored in a binary repository like Azure Artifacts, JFrog Artifactory, or Nexus.

The manual approval step might use Azure Pipelines’ release gates or environments with checks. Infrastructure as code (IaC) tools such as Terraform, ARM templates, or Bicep are often used to provision and configure environments consistently. Key metrics in continuous delivery include deployment frequency, lead time for changes, mean time to recover (MTTR), and change failure rate.

Certified tools for implementing continuous delivery on Azure include Azure Pipelines, Azure DevOps Services, and GitHub Actions. The practice aligns with the DevOps principle of reducing silos between development and operations. In an enterprise context, continuous delivery supports compliance and auditability because every release is traceable through the pipeline logs and approval records.

It also enables techniques like canary releases, blue-green deployments, and feature flags because the release process is standardized and repeatable. The Azure AZ-400 exam specifically covers the design and implementation of release strategies as part of the 'Implement release management' objective domain. Candidates must understand how to configure multi-stage YAML pipelines in Azure Pipelines, integrate approval gates, and manage release variables and secrets.

In practical IT, continuous delivery matters because it directly addresses the high costs and risks associated with manual software releases. Traditional release processes often involve dedicated release windows, late-night deployment calls, and manual steps like copying files, running scripts, and updating databases. These manual processes are error-prone and slow.

A single misconfigured step can cause downtime, data loss, or security vulnerabilities. Continuous delivery eliminates these risks by automating the entire release pipeline, ensuring every change is validated and ready. This allows IT teams to release updates more frequently, sometimes multiple times per day, without increasing the risk of failure.

For businesses, this translates into faster time-to-market for new features, quicker bug fixes, and improved customer satisfaction. It also reduces the cognitive load on operations teams because deployments become routine, low-stress events rather than high-anxiety emergencies. From a compliance perspective, continuous delivery provides a clear audit trail of every change, including who approved what and which tests passed.

This is critical for regulated industries like finance or healthcare, where audits require proof of controlled releases. Continuous delivery enables modern architectural patterns like microservices, where each service can be updated independently. Without CD, coordinating releases across hundreds of microservices would be impossible.

Finally, continuous delivery supports a culture of experimentation. Since it is easy to release changes, teams can run A/B tests, gradually roll out features, and quickly roll back if something goes wrong. This leads to better software and more innovation.

In the AZ-400 exam, continuous delivery appears in several question patterns. The most common type is scenario-based: the question describes a software team with specific needs, and you must choose the best release strategy. For example, 'A company wants to automate all steps up to production but still requires a human to click deploy.

Which practice should they implement?' The correct answer is continuous delivery. Another pattern involves pipeline configuration: you are given a YAML snippet with missing stages or incorrect dependencies, and you must identify the fix.

For instance, the snippet might have a build stage that produces an artifact, but the release stage does not reference the artifact correctly. You would need to add an artifact download step. A third pattern is troubleshooting: the question might say that a release to staging failed because the database migration script ran out of order.

You must identify that the pipeline should include a separate database migration step before the application deployment or use tools like Flyway or Entity Framework migrations in the pipeline. Another common pattern is about approval gates: the question might describe a scenario where a manager must approve releases to production. You need to know how to configure an environment in Azure Pipelines with required approvers.

Questions may also ask about artifact versioning: for example, 'A team uses semantic versioning for their NuGet packages. How should they configure the pipeline to automatically increment the version?' The answer would involve using a versioning task or a script that reads the version from a file.

You might also see questions that differentiate between continuous delivery and continuous deployment, especially when a scenario mentions automatic release to production. Questions about release strategies might ask: 'Which deployment method allows you to route a small percentage of traffic to the new version before full rollout?' The answer is canary release, which is enabled by a mature continuous delivery pipeline.

In practice, implementing continuous delivery requires more than just setting up an Azure Pipeline. You need a mature testing strategy. Unit tests are fast but catch only logic errors.

Integration tests check that components work together, and end-to-end tests verify user flows. A common mistake is relying only on unit tests, which leads to bugs slipping through the pipeline. Professionals use test pyramid principles: many unit tests, fewer integration tests, and even fewer e2e tests.

Another critical aspect is managing configuration. Environment-specific values like connection strings, API keys, and feature flags should not be hardcoded into the artifact. Instead, use Azure App Configuration, Azure Key Vault, or pipeline variables to inject settings at deployment time.

This ensures the same artifact can be deployed across dev, staging, and production without recompilation. Secrets must be handled securely; never commit secrets to source control. Use Azure Key Vault with managed identities in the pipeline to retrieve secrets at runtime.

Another common concern is database changes. Database migrations must be included in the pipeline. Tools like Flyway, Liquibase, or Entity Framework migrations can run scripts as part of the deployment.

The key is to ensure that database changes are reversible and that the application code is backward-compatible with the previous database version. This allows for safe rollbacks. Infrastructure as code (IaC) is also essential.

Without IaC, staging environments may drift from production, leading to 'it works on my machine' problems that surface only in production. Use ARM templates, Bicep, or Terraform to provision environments consistently. Finally, monitoring and feedback loops complete the CD pipeline.

After deploying to production, the pipeline should trigger automated smoke tests and send telemetry to Azure Monitor or Application Insights. If error rates spike, the team should be alerted immediately, and the pipeline should support automated rollback. A well-tuned CD pipeline reduces mean time to recover (MTTR) and increases overall system reliability.