General Musing

blaze your trail

Posts Tagged ‘continuous

Continuous Integration vs Continuous Deployment

leave a comment »

Continuous Integration and Continuous Delivery or Deployment are terms which are often heard, and the former is sometimes confused with the later. So what are they and why should you care?

Continuous Integration (CI) is a process of linking the code the code that is being developed in the company into a quality control system. This can be for homogenous or heterogeneous code environments. A simple example is of a tool which is being developed in the company by multiple developers. To ensure that the new code complies with all the new requirements and still works with the existing code or data model, a set of automated unit, functional, integration and verification/validation tests are created to verify that this true. All the test sets can cover different parts of the functionality from low level code tests to the highest level user experience tests. The final acceptance is done by a human and deployed explicitly.

With Continuous Deployment (CD) the philosophy is taken one step further. Rather than having a final acceptance by a human who would deploy the application explicitly, the assumption is made that the level of testing is sufficient that the final manual stage can be automated. This means that the live/production software is continuously replaced with the newest version that passed all the tests.

As I first explain the process of CI most developers, they are quite enthusiastic. Once they realize that it means that they need to write unit tests they suddenly start thinking it sounds quite difficult. They think that they need a well-developed test-suite required to achieve automated testing advantages. This is naturally not true. Just as with writing new code unit tests can be created incrementally for existing code. Before changing any existing code first write a suitable test which ensures that the changed code will perform in the same way as the existing code so as not to break the existing code or any of its dependancies.

Whereas while first explaining the process of CD to most development teams they think that it is impossible to continuously deliver software that could be deployed directly to the live environment or customer. Yet they forget that in many cases they themselves are guilty of deploying less rigorously tested software into a production environment. Many managers usually simply state that it cannot be done. And it usually cannot be done before a CI has been in place for a while, and unlike CI it needs more than just a large set of unit tests. It also needs a test suite of functional, integration and validation tests.

What I consider most important for CD is to change the way bugs or suspected bugs are handled. Currently many bugs are closed with the message “could not reproduce”. In a CD environment there is no reason to not write validation tests for all bug reports. Consider it possible that all bugs, including irreproducible bugs, are suggestions for validation tests, if you believe that a bug should not happen it should be tested for.

Image source: xt0ph3r


Written by Daniël W. Crompton (webhat)

July 24, 2012 at 1:12 pm

%d bloggers like this: