Continuous delivery

What is continuous delivery?

Continuous Delivery (CD) is the software development process of getting code changes into production quickly, safely and with higher quality usually using tools to automate the deploys. Engineering teams make changes to their software in short cycles, so that it can be tested and released more frequently. This approach allows for incremental changes with both lower costs and risk. The approach was first popularized by Jez Humble and David Farley in their book, Continuous Delivery: Reliable Software Releases Through Build, Test, and Deployment Automation.

How does continuous delivery work?

Here's a breakdown of the continuous delivery process:

• Continuous Integration (CI): Teams integrate code changes into a shared repository frequently. Automated tests run on these changes to ensure the codebase remains functional.
• Automated builds: Whenever new code is committed, an automated build process starts, compiling code and creating executable artifacts.
• Automated testing: Automated tests (unit tests, integration tests, etc.) validate the functionality of the code. If the tests pass, the code moves forward.
• Deployment pipeline: Code that has passed the tests moves through a deployment pipeline. This pipeline consists of stages such as staging, testing, and production.
• Automated deployment: If code changes pass all stages, they are automatically deployed to production or a production-like environment.

Why you need both continuous delivery and A/B testing

Continuous delivery ensures efficient software deployment, while A/B testing validates changes, ensuring they meet user needs. Integrating both enables high-quality software driven by user feedback and data insights.

1. Quality assurance
   

   CD delivers updates swiftly, while A/B testing validates changes with real user data, ensuring effective deployments that enhance user experience. Updates not only arrive swiftly but are also optimized.

2. Improvement
   

   A/B testing lets teams refine CD-deployed features incrementally based on user feedback, leading to better-performing products.

3. Data-driven decisions
   

   Integrating A/B testing in CD gathers early insights, guiding feature prioritization and deployment decisions.

Benefits of continuous delivery

Below are the primary benefits to a continuous delivery pipeline in the cloud.

1. Speed to market
   

   Market conditions are in a perpetual state of constant change as consumer behavior shifts. Products can suddenly catch on or, just as suddenly, decline. At the same time, technological advances can also affect the need to release changes more quickly to your end users. To respond to unpredictable market and technology changes, it’s quicker for engineers to release software using continuous delivery.

2. Lower risk
   

   When incremental changes are released more frequently, errors can be spotted and corrected earlier in the development process. It’s also easier to roll back smaller changes when necessary and helps prevent unintended changes from entering the production environment through version control and the use of a staging environment. Leveraging automated testing as well as breaking tests into smaller unit tests are other DevOps best practices that reduce downtime.

3. Coordination and communication between teams
   

   With continuous delivery, teams share responsibility for software delivery. This breaks down the silos between groups or departments, and removes the unpredictability and stress from software release. Deploying more frequent releases is a process that gets the team working at a regular, predictable pace.

4. Quicker learning cycle
   

   Releasing new features more quickly to market means more timely feedback from your customers. This release process allows you to learn from your customers by getting working software into their hands sooner, incorporate their feedback and make adjustments to your product to improve it.

Continuous delivery example

Imagine an e-commerce platform that wants to experiment with a new checkout flow to improve conversion rates. 

• Idea generation: Identify the need for a new checkout flow to improve conversions.
• Development: Create two checkout versions. A (current flow) and B (New optimized flow)
• CI and deployment: Test both versions in a staging environment via Continuous Integration.
• A/B testing: Use feature toggles to direct users randomly to Version A or B.
• Data collection: Track user metrics (conversion rates, abandonment) in both versions.
• Analysis: Compare performance metrics to determine the better-performing checkout flow.
• Deployment: If Version B excels, deploy it platform-wide via CD.
• Monitoring: Continuously monitor and refine the new flow based on user feedback and data.

Continuous delivery & DevOps

The terms ‘DevOps’ is a combination of ‘development’ and ‘operations,’ denoting the collaboration between the two. DevOps shares common goals and traits with continuous delivery. Each delivers small changes, relies on collaboration and coordination between teams and shares a common goal of faster time to market.

To clarify the difference between the two, DevOps is the methodology for helping companies build and release software. It’s the practice that emphasizes collaboration and coordination between the software developers and other departments in the company. DevOps creates an environment where software can be developed, tested and released quickly and reliably.

You can think of DevOps as the larger force and philosophy behind the service, while continuous delivery is the process that delivers it in the cloud.

Continuous delivery vs continuous integration

In traditional software development, the process of integration occurs at the end of a project after each person finishes their work. This process can take a long time and be frustrating for all involved.

Continuous integration is a software development practice that moves the integration phase up in the development cycle so that developing, testing and integrating code happens with greater frequency. The development team merges code changes into a shared, central repository several times a day in order to release a product version at any moment. This requires an integration process which is reproducible and automated.

Continuous delivery vs continuous deployment

In the practice of continuous deployment, all software changes that pass testing automatically go to production. To create a continuous deployment pipeline, your company needs to get to continuous delivery first.

Continuous deployment can be considered an extension of continuous integration, with a goal to minimize the time lapse between writing new code and the new code being used in the production code base.

To achieve continuous deployment, the development team relies on a rigorous process that automates the various steps leading up to deployment. After each integration meets release criteria, the live application is updated with new code and a production deployment can happen.

Agile development and continuous delivery

Agile software development holds a set of values and principles whereby requirements and solutions evolve through team collaboration. It embraces adaptive planning, early delivery, continuous improvement and flexible response to change. In agile, there is no set time frame for each release, but the idea is that they occur frequently: perhaps every few weeks or every few months, with a preference for the shorter of the two.

In the evolution of processes for software delivery, agile development preceded continuous delivery.

Continuous delivery is a subset of agile in which the team keeps its software ready for release at all times during development. It is more about developing in such a way that the software is always ready for release – continuously.

Continuous delivery and A/B testing

Experimentation and feature management need to work hand-in-hand. Experimentation is an important way for your company to validate ideas prior to launching new products, features, and experiences to all visitors. With development teams that use continuous integration and continuous delivery process, feature flags that control the rollout of new experiences can mitigate the risk of launching something unproven to everyone at the same time.

To help keep A/B testing as a key part of your organization’s deployment process, Optimizely server-side experimentation integrates feature flags, rollouts, and variables with experimentation, allowing you to control the entire product development lifecycle in one place. By first running an A/B test to a portion of traffic, your team can test and gradually optimize a new feature. Once you have the best user experience, it can be rolled out in a controlled way across your entire customer base to reduce the risk of any engineering issues with the release process.