DevOps, from continuous integration to continuous deployment

The first steps towards industrialized developments usually start with continuous integration.

Although it is often seen as an achievement in itself, it's actually only a piece of an efficient and managed solution.

Translated from the article published in the July-August 2014 ICT Journal (french).

Continuous integration, an unquestionable basis

Keystone to a software factory, the continuous integration server is essential to any software development project. Whether you pick Jenkins, Bamboo or anything else, it ensures code compilation, running of unit tests, packaging, deployment and integration tests execution. But its main perk is its independence from developers' local settings. This guarantees unbiased quality rules matching (enforced with SonarQube, for instance) and asserts processes repeatability

The packaged code is archived into an archetype repository. This archive will be deployed on each environment, including production.

Continuous integration secures development activities. Once set up, it allows the project organization to push industrialization beyond the development team boundaries.

Automated deployment, a must have

It is now possible to gradually automate deployment actions that used to be manually executed by the operations team (database updates, deployments to an application server, etc.).

Not only will this automation remove tedious tasks, but it will also secure the deployment process while increasing the shipping frequency for early user validation.

These automated deployments extend from deployment scripts in simple cases to a complete setup of the destination environment (with tools such as Puppet, Chef or Docker). Just like regular code, these scrips and configurations are to be stored under version control.

This step cannot be achieved without a genuine collaboration between development and operations teams.

When it's done, the deployment to integration can already be automated and triggered frequently, as long as it doesn't affect any other team. Developers can then rapidly test their code in an environment similar to production.

However, deployments are triggered manually for qualification and production environments, so as to keep stakeholders (project members, customers and decision-makers) reassured while providing a significantly shorter delay.

Automated acceptance tests, an ideal

To improve the time-to-market any further, execution duration of manual acceptance tests in qualification environment must be reduced. Testers who used to spend their time running these tests repeatedly can now use it to write automated tests. Thus, the quality of these tests and their coverage will reach a higher level, ensuring a better match between the application and the users' expectations.

Running automated acceptance tests requires an automated application deployment, which removes more manual steps and eases the delivery process.

Continuous deployment to production, the holy grail?

Nowadays, continuous integration is widely adopted and its efficiency is well established. It is a prerequisite to anyone willing to improve his development practices.

Automated deployment to integration environment is a growing practice. It increases developers' awareness of their own achievements.

Acceptance tests automation is less widespread. It adresses an enhanced industrialization of the development processes and enables a shorter time-to-market.

Once the development line until qualification is mastered, there is but one step towards continuous deployment to production. Only a handful of key players have crossed that line, because of the nature of their trade (Google, Twitter, Amazon, etc.).

In such cases, the human impact is so big that this change is felt as the biggest one. Notable organizational obstacles remain (norms conformity, timidity, communication on new releases), and the upside may not be obvious to everyone.