Continuous delivery of distributed applications

Image: Danilo Rizzuti / FreeDigitalPhotos.net

Continuous integration has become the bread and butter of most development teams to insure that code changes from a team of developers are automatically built and tested to detect integration errors as early as possible.

Continuous delivery goes one step beyond that by extending the chain and making automated builds available for production. A pre-requisite for continuous delivery is system integration testing. Automating system integration testing is more difficult than unit testing, particularly for applications with many moving parts deployed on more than one servers.

A key-step in  implementing Continuous Delivery is to extend your CI process with an automated software configuration and deployment management system.


The first rule of software non-regression testing is

The earlier you discover an issue the easier it is to fix

Quite obviously, it is much easier for a developer to resolve an issue in code he pushed one hour ago than one that was introduced a week earlier. This is the driving philosophy behind Continuous Integration. Unfortunately, unit-testing has its limits for distributed applications with collaborating services.

The main hurdle is the difficulty to automate the deployment of n-tier software. That is why many organizations end up performing system integration testing on manually installed "snapshots" on a weekly basis at best. Consequently, the trickier issues resulting from the interactions between processes are discovered only after developers have switched context to other tasks and take much more effort to resolve.

Automating system integration testing is a must have but to be fully effective it must be inserted in a Continuous Deployment process where the latest builts (from one or more development teams) are assembled and automatically installed by a deployment automation tool. Tools like capistrano or ant have all the necessary features if you don't mind being tied to a single language, respectively ruby on rails or java. Since many real-world applications use combinations of technologies, or might in the future, it is preferable to select a more generic tool.

KwateeSDCM is not a Continuous Delivery platform but it is a key component of the process. Besides providing the necessary automation (RESTFul API) and being fully language and platform agnostic, KwateeSDCM has the additional benefit of managing configuration parameters of the deployed software modules making it possible to automate system integration testing on multiple environments and configurations.