(this post originally written for Daitan Blog)
Once upon a time, people just wrote code and then run it to find how well it worked. Working individually, the developer was able to iterate quickly until the software was useful to solve a real problem.
By the 1990’s, as software became more complex, it was broken into separate and independent sub-modules developed more or less in isolation by individual developers. Each sub-module was tested, the system was integrated back together, then tested, staged, released, deployed. Software development cycles stretched over several months (or several years).
The pendulum is swinging back. Software engineering is now evolving towards shortening the feedback loops and minimizing the time it takes from code being written and being in production. This time, we want to do it with more quality and predictability. The tools to achieve that are processes, automation, and collaboration.
Moving across the levels depicted on the picture above (Source Code Control, Build Automation, Test Automation, Continuous Integration, Release Automation, Continuous Delivery) is not simple. It involves not only changing processes and automating them, but also changes in culture and organization.
- Source Code Control – Single source code repository with version control.
- Build Automation – Compile and Build applications without human intervention.
- Test Automation – Execute unit, integration and service tests without human intervention.
- Continuous Integration – Developers integrate code into a shared repository (which triggers automated build/test) often.
- Release Automation – Packaging, deploying and post-deployment testing without human intervention.
- Continuous Delivery – Every change to the system is releasable. Release can be done by the push of a button.
Continuous Integration
Continuous Integration (CI) is the practice of accelerating the daily commits of code by software developers. If in the past developers would work for weeks before trying to integrate their work to the main tree, in a CI environment you want developers to check-in their work several times a day.
A CI server monitors code check-outs and check-ins by developers and, as often as practical, it builds the system and runs unit and integration tests. If there is any failure in the process, the CI server alerts the developers. A broken build gets the attention and top priority from the team.
CI requires test-driven development and automation.
Benefits:
- CI does not eliminate software bugs, but it accelerates their discovery and keeps people from going in the wrong direction for too long.
- The system is always in a state that can be released to users. That provides more flexibility to the business and enables the automation of the release process and delivery to users.
Continuous Delivery
Once you are doing Continuous Integration and is able to automate the deployment process, you can consider extending the process and automation all the way to the end-user. Continuous Delivery (CD) is the practice and ability to rapidly, reliably and repeatedly push out enhancements and bug fixes to customers at low risk and with minimal manual overhead.
The automation system let changes to the system be released on a granular basis. Releasing features just to a subset of users and being able to seamless roll back to a previous version become possible.
The result is that there is no delay between enhancements and bug fixes being implemented and available to users.
Marcio Saito 