Continuous Integration, Continuous Delivery and Continuous Deployment
Continuous Integration is a software development practice where members of a team integrate their work frequently; usually each person integrates at least daily - leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly.
Continuous Integration practices
Single source repository
Automate the build
Make your build self testing
Everyone commits everyday
Every commit triggers a build
Fix broken builds immediately
Keep the commit build fast (and use pipeline for slower builds)
Test in a clone of the prod environment
Make it easy to get the latest build
Visibility
Automate deployment
Continuous Delivery is a software development discipline where you build software in such a way that the software can be released to production at any time.
You are doing continuous delivery when:[1]
Your software is deployable throughout its lifecycle
Your team prioritizes keeping the software deployable over working on new features
Anybody can get fast, automated feedback on the production readiness of their systems any time somebody makes a change to them
You can perform push-button deployments of any version of the software to any environment on demand
You achieve continuous delivery by continuously integrating the software done by the development team, building executables, and running automated tests on those executables to detect problems. Furthermore you push the executables into increasingly production-like environments to ensure the software will work in production. To do this you use a DeploymentPipeline.
The key test is that a business sponsor could request that the current development version of the software can be deployed into production at a moment's notice - and nobody would bat an eyelid, let alone panic.
To achieve continuous delivery you need:
a close, collaborative working relationship between everyone involved in delivery (often referred to as a DevOpsCulture[2]).
extensive automation of all possible parts of the delivery process, usually using a DeploymentPipeline
Continuous Delivery is sometimes confused with Continuous Deployment.
Continuous Deployment means that every change goes through the pipeline and automatically gets put into production, resulting in many production deployments every day.
Continuous Delivery just means that you are able to do frequent deployments but may choose not to do it, usually due to businesses preferring a slower rate of deployment. In order to do Continuous Deployment you must be doing Continuous Delivery
Continuous Integration usually refers to integrating, building, and testing code within the development environment.
Continuous Delivery builds on this, dealing with the final stages required for production deployment.
The principal benefits of continuous delivery are:
Reduced Deployment Risk: since you are deploying smaller changes, there's less to go wrong and it's easier to fix should a problem appear.
Believable Progress: many folks track progress by tracking work done. If "done" means "developers declare it to be done" that's much less believable than if it's deployed into a production (or production-like) environment.
User Feedback: the biggest risk to any software effort is that you end up building something that isn't useful. The earlier and more frequently you get working software in front of real users, the quicker you get feedback to find out how valuable it really is (particularly if you use ObservedRequirements).
One of the challenges of an automated build and test environment is you want your build to be fast, so that you can get fast feedback, but comprehensive tests take a long time to run. A deployment pipeline is a way to deal with this by breaking up your build into stages. Each stage provides increasing confidence, usually at the cost of extra time. Early stages can find most problems yielding faster feedback, while later stages provide slower and more through probing. Deployment pipelines are a central part of ContinuousDelivery.
Usually the first stage of a deployment pipeline will do any compilation and provide binaries for later stages. Later stages may include manual checks, such as any tests that can't be automated. Stages can be automatic, or require human authorization to proceed, they may be parallelized over many machines to speed up the build. Deploying into production is usually the final stage in a pipeline.
More broadly the deployment pipeline's job is to detect any changes that will lead to problems in production. These can include performance, security, or usability issues. A deployment pipeline should enable collaboration between the various groups involved in delivering software and provide everyone visibility about the flow of changes in the system, together with a thorough audit trail.
A good way to introduce continuous delivery is to model your current delivery process as a deployment pipeline, then examine this for bottlenecks, opportunities for automation, and collaboration points.
Continuous Delivery (CD) is a software strategy that enables organizations to deliver new features to users as fast and efficiently as possible. The core idea of CD is to create a repeatable, reliable and incrementally improving process for taking software from concept to customer. The goal of Continuous Delivery is to enable a constant flow of changes into production via an automated software production line. The Continuous Delivery pipeline is what makes it all happen.
The pipeline breaks down the software delivery process into stages. Each stage is aimed at verifying the quality of new features from a different angle to validate the new functionality and prevent errors from affecting your users. The pipeline should provide feedback to the team and visibility into the flow of changes to everyone involved in delivering the new feature/s.
There is no such thing as The Standard Pipeline, but a typical CD pipeline will include the following stages: build automation and continuous integration; test automation; and deployment automation.
Your Pipeline Needs Platform Provisioning and Configuration Management
The deployment pipeline is supported by platform provisioning and system configuration management, which allow teams to create, maintain and tear down complete environments automatically or at the push of a button.
Automated platform provisioning ensures that your candidate applications are deployed to, and tests carried out against, correctly configured and reproducible environments. It also facilitates horizontal scalability and allows the business to try out new products in a sandbox environment at any time.
Orchestrating it all: Release and Pipeline Orchestration
The multiple stages in a deployment pipeline involve different groups of people collaborating and supervising the release of the new version of your application. Release and pipeline orchestration provides a top-level view of the entire pipeline, allowing you to define and control the stages and gain insight into the overall software delivery process. By carrying out value stream mappings on your releases, you can highlight any remaining inefficiencies and hot spots, and pinpoint opportunities to improve your pipeline.
Don’t Add New Functionality Until You Get The Quality Right!
Poor system quality, low-user satisfaction and endless “quality band-aids” can be avoided by adopting the principle of not adding new functionality before getting the quality right. You should always first meet and maintain your quality levels and only then consider gradually adding functionality to the system.
Starting out on CD
Define a process
Ensure a blameless culture
Set metrics and measure your success
Adopt configuration as code
Orchestrating a process
You’ve defined your pipeline; now you need to orchestrate it. This is a long process, but here are a few steps you’ll want to take – as outlined in a whitepaper by Xebia Labs’ Andrew Phillips and CloudBees’ Kohsuke Kawaguchi.
Ensure reproducible builds – Configure the build system to use a clean repository connected to the build job’s workspace and use a central shared repository for build dependencies.
Share build artefacts through the pipeline – Ensure the candidate artefact is used by all subsequent builds in your pipeline.
Choose the right granularity for each job – Distribute all steps in the pipeline across multiple jobs, allowing you to identify bottlenecks more easily.
Visualize the pipeline – Create a clear, accessible view of the build pipeline to allow for smooth status communications and transparency of the process to the business managers and other stakeholders.
Continuous Testing is one of several continuous activities that should take place simultaneously in a DevOps pipeline, including
Continuous Build;
Continuous Integration (CI);
Continuous Delivery (CD); and
Continuous Deployment.
Continuous Build or build automation is the first stage in implementing a Continuous Delivery DevOps pipeline. If your developers are practicing test-driven development (TDD), they'll write unit tests for each piece of code they write, even before the code itself is written. An important part of the agile methodology, TDD helps developers think through the desired behavior of each unit of software they're building, including inputs, outputs, and error conditions. New features implemented by developers are then checked into a central code base prior to the software build, which compiles the source code into binary code.
Remember, Delivery means the ability to deploy to production. Deployment means actually doing so.
Continuous deployment depends on continuous delivery which depends on continuous integration.
KPIs/metrics for CI/CD
• Cycle time
• Test coverage, cyclomatic complexity, duplication, etc
• Number of defects
• Velocity
• # Commits per day
• # Builds per day - success, failures and total
• Duration of build
Deployment Pipeline
At an abstract level, a deployment pipeline is an automated manifestation of your process for getting software from version control into the hands of your users. Every change to your software goes through a complex process on its way to being released. That process involves building the software, followed by the progress of these builds through multiple stages of testing and deployment. This, in turn, requires collaboration between many individuals, and perhaps several teams. The deployment pipeline models this process, and its incarnation in a continuous integration and release management tool is what allows you to see and control the progress of each change as it moves from version control through various sets of tests and deployments to release to users.
Thus the process modeled by the deployment pipeline, the process of getting software from check-in to release, forms a part of the process of getting a feature from the mind of a customer or user into their hands. The entire process—from concept to cash—can be modeled as a value stream map. A high-level value stream map for the creation of a new product is shown below:
This value stream map tells a story. The whole process takes about three and a half months. About two and a half months of that is actual work being done—there are waits between the various stages in the process of getting the software from concept to cash. For example, there is a five-day wait between the development team completing work on the first release and the start of the testing process. This might be due to the time it takes to deploy the application to a production-like environment, for example. As an aside, it has been left deliberately unclear in this diagram whether or not this product is being developed in an iterative way. In an iterative process, you'd expect to see the development process itself consist of several iterations which include testing and showcasing. The whole process from discovery to release would also be repeated many times.
A Basic Deployment Pipeline
The process starts with the developers committing changes into their version control system. At this point, the continuous integration management system responds to the commit by triggering a new instance of our pipeline. The first (commit) stage of the pipeline compiles the code, runs unit tests, performs code analysis, and creates installers. If the unit tests all pass and the code is up to scratch, we assemble the executable code into binaries and store them in an artifact repository. Modern CI servers provide a facility to store artifacts like these and make them easily accessible both to the users and to the later stages in your pipeline. Alternatively, there are plenty of tools like Nexus and Artifactory which help you manage artifacts. There are other tasks that you might also run as part of the commit stage of your pipeline, such as preparing a test database to use for your acceptance tests. Modern CI servers will let you execute these jobs in parallel on a build grid.
The second stage is typically composed of longer-running automated acceptance tests. Again, your CI server should let you split these tests into suites which can be executed in parallel to increase their speed and give you feedback faster—typically within an hour or two. This stage will be triggered automatically by the successful completion of the first stage in your pipeline.
At this point, the pipeline branches to enable independent deployment of your build to various environments—in this case, UAT (user acceptance testing), capacity testing, and production. Often, you won't want these stages to be automatically triggered by the successful completion of your acceptance test stage. Instead, you'll want your testers or operations team to be able to self-service builds into their environments manually. To facilitate this, you'll need an automated script that performs this deployment. Your testers should be able to see the release candidates available to them as well as their status—which of the previous two stages each build has passed, what were the check-in comments, and any other comments on those builds. They should then be able to press a button to deploy the selected build by running the deployment script in the relevant environment.
Sequence of Gates (Deployment Pipeline)
