Continuous Delivery vs. Continuous Integration- What’s the Difference?

 

This post discusses the terms Continuous Integration, Continuous Delivery, Continuous Deployment, Continuous Delivery Pipeline and Continuous Delivery Environment in order to help clear up any confusion with the many terms.

Let’s start with Continuous Delivery and Continuous Integration which are often confused. These two terms describe two distinctively different processes involving the building, deploying, testing, and releasing of a product.

Continuous Integration is the practice of mandating that code is frequently and continually merged into version control. This is to ensure the code base remains in a working state. It’s an important step toward achieving Continuous Delivery.

Continuous Delivery is the practice of moving that code out to users of various environments for testing, demo, or most importantly production. If you’re in the custom software development business, your probably not surprised that deploying to different environments is challenging.

Let’s delve into both Continuous Integration and Continuous Delivery a little more.

Continuous Integration

Continuous Integration was first discussed in Kent Beck’s book Extreme Programming Explained in 1999. The premise of Continuous Integration is that code base changes are automatically integrated into the application. Thus, every time code is checked into version control it automatically attempts to integrate into the development environment. If the attempt fails, the entire development team is responsible for stopping what they are doing and fixing it. The imperative is to keep the environment in a working state. If the issue cannot be resolved, it can easily be rolled back to its prior state. Then the developer or team who checked the code in can resolve the issue.

Continuous Integration offers many benefits, including:

• Ensuring that the software is constantly in a working state.
• Allowing the team to deliver software faster and with fewer defects (thanks to automated tests at check-in).
• Increasing the team’s efficiency by eliminating the problems of waiting until a milestone (such as a demo or release) and painfully finding out and troubleshooting multiple issues of unknown origin.
• When you integrate frequently such as every day or several times a day the changes are smaller and therefore easier to address when something goes wrong.

It is important to note that Continuous Integration itself is not a tool, environment or script. Continuous Integration is an agreed upon practice of the team. While there are many commonly available tools to help make this happen, they are merely the supporting actors and not the play.

Here are some things to keep in mind when applying the practice of Continuous Integration:

• Agree on and apply the Continuous Integration practice from the beginning of the project. It is much easier to develop a project plan utilizing this practice from the start then begin to integrate it sometime in the middle of the project. Smaller, less frequent changes means less time consuming troubleshooting.
• Working on parallel branches in version control can be an impediment to Continuous Integration. This is because it goes against the general principle of frequently merging into the main code line (trunk).

Continuous Delivery

Learn Why Continuous Delivery Delivers

Continuous Delivery is the process of utilizing best practices to deliver working, tested code to users through another environment. Continuous Delivery encompasses much more than just the code, as it is the entire application environment needed for the application to work. The supporting environment includes complex items, such as the OS, web server (possibly), compiled binaries, permissions, database and data, third party components, and the entire configuration for each of these. It includes the entire dependency of each and every component in this system.

In order to frequently deliver working code into various environments such as QA, (Quality Assurance), UAT (User Acceptance Testing), Demo or production Continuous Delivery requires full automation or as close as absolutely possible.

Here are the major benefits of Continuous Delivery:

• Working software is deployed to any environment with just the push of a button.
• Code is delivered to a user base for continual review and inspection.
• Small batches of work can be continually filtered up to the next step, which will help identify any issues early on and keep the developer working to fix any problems while the issues are top-of-mind.

Here are some things to consider with Continuous Delivery:

• To get to that “push of a button” is no simple feat; there is a lot involved in making this automation happen across multiple environments. These challenges can present barriers to busy development teams and DevOps groups.
• It’s important for a DevOps team to approach a project with Continuous Delivery from the beginning.

Just when you thought you had Continuous Integration and Continuous Delivery down, here we go throwing in another term that’s important to mention. So, let’s quickly talk about Continuous Deployment.

Continuous Deployment is the process of deploying to production whenever a feature is ready or at least frequently. It requires Continuous Integration and Continuous Delivery, as well as an automated process. For optimal workflow and success, the entire process would ideally be fully automated from start to finish.

Continuous Deployment can offer the following benefits:

• It creates smaller, faster deployments that are less risky.
• It fosters the positive image that the DevOps team and company are constantly improving their product.
• It creates a more digestible product to the user compared to a big release in which productivity may be temporarily affected by a new learning curve.

Before we go we might as well clear up a few more terms.

A Continuous Delivery Environment is a fully automated or nearly fully automated system that supports the rapid development of high quality software. That includes build, test and deployment. The environment will typically use a variety of tools and scripts to enable the automation to eliminate the boring tasks, consumption of time and manual error (aka risk).

Finally, one more term you may hear is a Continuous Delivery Pipeline. The Pipeline is the process that defines Continuous Delivery. Most pipelines will have similar basic operations such as build and test automation, continuous integration and deployment automation. However, each process will look different for a given organization. Below is an example of a high-level deployment pipeline diagram.

Conclusion: While each concept has its own role to play, together, Continuous Integration, Continuous Delivery, and Continuous Deployment can greatly improve your team’s processes involving the building, deploying, testing, and releasing of a product.

Find Out the #1 Reason Agile Fails

Continuous Integration vs. Continuous Delivery- What’s the Difference

You may also be interested in: The Business Case for Cloud-based Continuous Delivery Environments

Third Wave is a boutique software development company located in Boca Raton, Florida. Our business acumen, agile development solutions, and perfected continuous development process offer unmatched levels of expertly crafted software and development services. Our team is dedicated to helping companies break into the new era of rapidly changing business trends with adaptive technology that provides sophisticated business solutions.

Third Wave also offers Cloud CDE, a fully automated cloud-based Continuous Delivery Environment “in a box”. Cloud CDE and our consulting services provide a jump start to organizations that are ready to start transforming their culture to a high-performing IT organization.