continuous integration vs continuous delivery

Continuous Delivery vs. Integration vs. Deployment: differences

In the past few years we’ve seen the concepts Continuous IntegrationContinuous Delivery and Continuous Deployment rise in popularity. Together with the fenomenon called DevOps, these concepts have been established as critical parts of the whole package and are being used in many various contexts without clear definitions. It’s a trending topic with many different articles and thoughts written about it.

For exactly that reason, we think it could be worth taking a closer look at what the concepts mean and the differences between them. Here are our thoughts and definitions of CI and the different types of CD.

Continuous Integration

The concept continuous integration (CI) can refer to one of two things, depending on the context.

It can refer to how a dedicated integration server such as Jenkins or TFS Build automatically tests new code. This is done in order to ensure a smooth integration with the existing code base. This type of automation enables individual developers to more continuously write and test code, which in turn decreases the risk of rework and faulty integration of code additions.

Continuous integration can also refer to the continuous integration of application changes throughout the entire delivery chain. In doing so, you often include the automated testing and integration made by a dedicated server as mentioned above, but also new design concepts and other types of testing.

In summary, continuous integration is about leveraging automation to ensure that the application is healthy at all times, especially as new code is committed. It helps developers avoid the dreaded situation where a new piece of functionality works well on individual machines but not integrates together.

Some benefits with using CI:

  • Fast and easy bug detection – leading to less bugs in production
  • Easier release process as integration is already taken care of earlier
  • Less context switching as developers are alerted the instant they break the build
  • QA saves time with less manual testing

Continuous Delivery

For the most part, continuous delivery (CD) means to uninterruptedly deliver updates to end users. When working with continuous delivery, you take automation a step further. Here, you aim at keeping the code in a state of releaseability at all times, regardless of whether or not the product is complete. Any working functionality should be releaseable at any time, even if you don’t want to deploy just yet.

This benefits business, as any code that successfully passes CI and logical tests can be released. With such, a continuous feedback loop between users or stakeholders and developers is possible – in turn, leading to better products and relationships. With automated build, testing and releasing at its code, continuous delivery can provide a massive competitive advantage.

This also means that continuous delivery cannot exist without continuous integration paired with an optimized development process.

A few benefits of doing continuous delivery are:

  • Reduced software complexity. With a bigger portion of the development cycle being automated, you will no longer need to spend valuable time preparing or setting up for a release.
  • You can release more often, which leads to higher quality and faster time-to-market.
  • Increased number of iterations. This brings many advantages, such as less risk of failure, faster recovery times and happier customers.

Continuous Deployment

The concept continuous deployment is in many ways similar to continuous delivery. The fact is that they are often used to describe the same thing (and are both abbreviated as CD).

However, some think there are differences. For example Micro Hering, DevOps and Agile lead at Accenture, means that continuous delivery is created by manual updates while the pipeline within continuous deployment is completely automated.

In such cases, continuous deployment doesn’t really care about making “when do we release?” a question at all. It simply states that since all code is releaseable, it should be released. In essence, every change – no matter how small or big – that passes all stages in the production pipeline will be released to the users. Since there’s absolutely no human interaction involved in this type of release, your developers can focus all their efforts towards writing great code. 

It is a nice way to cut feedback and iteration cycle times even further. However, before entering this stage, keep in mind that your testing quality is superb. If any error goes undetected, it will make its way into production and potentially cause failure and disruption. In addition, documenting the code becomes more important than ever. With a higher pace of development, you also need to document changes and additions in a similar pace. 

Benefits of continuous deployment

If you do succeed with this, here are some of the benefits:

  • Fast development. When there’s no time spent on anything else but development, you have the most resources available to you.
  • Releases become less risky as each update becomes very small.
  • Customers see value added continuously.

Continuous delivery/deployment/integration summary

In order to reach that dream scenario of continuous deployment, organizations and developers must incorporate automation. It’s the most important tool that modern developers have and is essential for keeping a high pace.

By defining and understanding these different concepts along with their advantages, your organisation can be more efficient in your development process. However, they all come with different benefits and challenges. To avoid disruption, make sure to take your time and work through any difficulties before moving on. The end result is worth doing it right for.

 

What do you think about the various “continuous” concepts? Do you agree or do you have some other definition? Let us know in the comments!

Leave a Reply

Your email address will not be published.