Continuous Delivery vs Continuous Deployment vs Continuous Integration
Continuous processes are vital to DevOps and agile development. These methodologies enable teams to release features, updates and fixes with great speed and accuracy. Yet, due to certain similarities, the lines between different continuous processes are often blurry.
This article points out the differences between continuous integration (CI), continuous delivery (CD), and continuous deployment (CD). Read on to learn more about these practices and see which one is the right fit for your team.
Continuous Delivery vs. Continuous Deployment vs. Continuous Integration: What Are the Differences
Here are quick summaries of the three practices:
Continuous Integration (CI): CI performs automatic integrations, builds, and code tests once a developer checks it in.
Continuous Delivery (CD): With CD, an automated release process happens after integrations, builds, and tests.
Continuous Deployment (CD): Every code change that goes through the production pipeline starts a deployment without the need for human intervention.
Continuous integration, delivery, and deployment overlap in several ways. CI is a vital part of both continuous delivery and continuous deployment. Continuous deployment covers the same processes as continuous delivery, except that releases happen automatically.
The table below compares continuous delivery, continuous deployment, and continuous integration:
Integration, delivery, and deployment are not mutually exclusive. A single pipeline can contain all three methodologies. Many CI/CD tools can help you set up and run an efficient pipeline.
Continuous Integration (CI)
Continuous integration involves a series of automatic steps that integrate code from multiple sources, create builds, and test software.
The main goals of CI are:
Release new updates quickly
Enable independent teams to collaborate on the same project
Identify and fix potential issues before they cause damage
CI may also include the integration of new design concepts to the DevOps pipeline.
How CI Works
CI requires the use of a continuous integration server, such as Jenkins or Bamboo. The CI server automatically tests code written by different developers.
Whenever a set of code or a build passes the local unit test, an automatic deployment takes the software to the staging environment. Once there, updates go through further testing, such as load or manual exploratory testing. The code then merges into the main code base.
Benefits of Continuous Integration
Build, integrate, and test new code segments in minutes
Developers work independently on features without compromising code stability
Deployments are faster and more predictable
Fewer production bugs
Immediate feedback in case of an issue
Eliminates the integration challenges of release days
QA team spends less time on manual testing in later stages
Encourages code transparency and code collaboration
Less context switching
Continuous Integration Requirements
A CI server that monitors the central repository (set up either on-premise or on the cloud)
Automated tests for every new improvement, feature, or bug fix
Continuous Integration Best Practices
Maintain a code repository
Always automate the software build
Keep builds as fast as possible
Make self-testing builds (Continuous Testing)
Commits to the baseline should occur daily
Run tests in a clone of the production environment
Make it simple to get the latest deliverables
Make the results of the newest build transparent
Continuous Delivery (CD)
On top of CI, continuous delivery also provides an automated release process after the integration and build stages. A manual trigger controls deployment to production.
The main goals of CD are:
Deliver new features when they are ready
Build stable, resilient systems
Ensure business applications operate without interruption
Continuous delivery relies on humans to decide what to release to the users and when. The deployment rate depends on the business requirements.
How CD Works
Developers add improvements, features, and bug fixes through a CI process. After a manual commit, CD tools take the code through an automated deployment pipeline.
Continuous delivery typically has a production-like staging area with a time lag in the final release. The lag enables reviewing and manually accepting the changes in the code before going to production.
Benefits of Continuous Delivery
Accelerated release cycles
Less time goes towards preparing and setting up releases
An increased number of iterations leads to fewer risks, shorter recovery times, and happier customers
Discover bugs early in the delivery process
Deliveries are more efficient and secure
A predictable delivery pace
Faster user feedback loops
Developers do less manual work
Continuous Delivery Requirements
A strong CI foundation
Optimizations at earlier stages of development
A test suite that covers enough of the code base
Feature flags to prevent incomplete features from affecting users in production
Continuous Delivery Best Practices
Ensure there is a robust CI setup supporting continuous delivery processes
Adjust your software systems to suit CD, not the other way around
Automate as many processes as possible
Use short, wide deployment pipelines
Have at least one stop between development and production
Deploy to all environments the same way
Drive changes from version control
Include the database in the pipeline
Monitor and log the delivery pipeline
Continuous Deployment (CD)
In continuous deployment, every code change goes through an automated pipeline, and working versions of the application are automatically released to production.
Unlike continuous delivery, continuous deployment does not have a release approval cycle. As there are no manual triggers, this setup depends on automatic testing to prevent bugs from reaching end-users.
The goal of continuous deployment is to enable an almost constant release of updates. Users receive updates as soon as developers write and test the code.
How Continuous Deployment Works
Whereas continuous delivery follows an on-demand model, continuous deployment pushes each deployment automatically. All testing occurs in production-like environments before merging to the mainline branch.
Continuous deployment does not need a staging area for manual reviews of code changes. Automated testing occurs early in the development process and goes throughout the release phases.
The differences between continuous delivery and deployment will continue to grow as tools like Docker make it easy to automate application deployment.
Benefits of Continuous Deployment
Automatic deployment triggers that require no human intervention
Deploy each new mainline addition to end-users
The team develops faster (no pause for releases and less manual, repetitive tasks)
Small code batches make releases less risky and easier to fix
A unified pipeline integrates teams and processes
Continuous Deployment Requirements
An excellent test suite
A documentation process able to keep up with the deployment pace
A sound feature flag system to support releases of significant changes
Continuous Deployment Best Practices
Maintain a central code repository
Automate as much of the build and deployment processes as possible
Commit to the baseline daily
Use an issue tracker for development tasks
Use a version control branch that contains issue numbers and descriptions of all changes
Which Continuous Practice is Right for You?
Before you consider which practice is the right fit for you, know that your team must have a DevOps culture capable of handling CI/CD. You should also account for potential restrictions, such as compliance laws. Regulations may prevent an organization from using continuous deployment.
If your team is capable of supporting continuous processes, ask yourself the following questions:
Does your team need a manual trigger between continuous integration and delivery?
Are you able to deploy without approval from a stakeholder?
Can you expose your users to production changes?
Are your response times to errors in production quick?
Do your gating requirements allow end-to-end automation
If you answered yes to the above questions, continuous deployment could be a worthwhile option. Consider automating your entire software delivery, from code commit to production.
If you answered no to some or all questions, you are better off starting with continuous integration and continuous delivery. Consider automating the creation of production-ready code, but have manual approval for deployment. Over time, your team can continue to grow towards continuous deployment and full automation of the software delivery process.
Make a Sound Business Choice
Continuous processes help build, test, and release software as quickly as possible, with as little bugs as possible. Yet, some methodologies work better in certain scenarios than in others.
A team must know the differences between continuous integration, delivery, and deployment to make the most out of those practices. Now that you understand what each process offers, pick the option that aligns with your needs, and ease your transition to DevOps.
Article Source : by BY ANDREJA VELIMIROVIC (click here for full article )