An engineering practice that seems to be more or less given if you are using any agile approach is continuous integration (CI), where a designated server or cloud based service polls your repository and kicks off a build whenever a change is detected. The main aim of CI is of course to prevent problems when integrating new code into the codebase, shortening the feedback loop for developers – so that the developers get almost instant feedback on whether or not they broke something with their last commit. One thing is feedback on whether or not the build of the code itself is doing ok after integration – the other is the suite of unit tests that also should run, getting feedback on whether the new code conflicts with existing functionality or have some unwanted side effects. Compare this approach to integration only at the time of release – a situation which begs for integration problems, or “integration hell” as it is called in the early descriptions of XP. When you also consider that a bug found 3 weeks from now takes up to 24 times longer to fix compared to a bug found today, you quickly realize that there is a lot to gain from using CI in your project.
If you take CI a step further and consider continuous delivery – that would be a series of practices designed to ensure that code can be rapidly and safely deployed to production by delivering every change to a production-like environment and ensuring business applications and services function as expected through rigorous automated testing. By deploying the newest changes to a staging environment using complete automation you will most probably get comfortable with the idea of doing the same to production, although this is not a necessary step in continuous delivery – instead a deployment to production is a manual decision, unless you have continuous deployment.
So once you are doing continuous delivery you can take the next step – continuous deployment. By using continuous deployment you will automatically deploy all new changes that passes all the automated tests (unit tests, acceptance tests ++) to production. Both continuous delivery and continuous deployment have similar benefits:
- Reliable Releases: You learn by doing and get good at what you do over and over again. So if you have continuous delivery your deployment process and scripts are tested repeatedly before deployment to production, and also you get a lot of practice of deploying to production by having continuous deployment. Compare this to the very unreliable process of only deploying to production maybe 3-4 times a year – there is almost always a lot of complications by not deploying often. So many things could have changed since the last time you deployed: not only code or configuration changes, but changes in staffing as well. Half the developers could have moved on to other teams by the time the deployment to production happens. If anything goes wrong (as it usually does in this setting), you are in a world of hurt.
- Shorter feedback loop: By releasing more frequent the development teams get user feedback more quickly. This enables the team to focus on features that are important to the users and helps building the right product. Doing things like A/B testing also becomes a lot easier, so that the team can really get to know what the user needs and wants.
- Accelerated Time to Market: Continuous delivery/deployment enables the teams to quickly deliver the business value inherent in new software releases to customers. This capability certainly could help the company stay a step ahead of the competition and could create a competitive advantage.
- Improved Productivity and Efficiency: Automation saves time for developers, testers and DevOps
- The quality of the product increases: Since new changes are continuously being delivered to staging by passing a rigorous set of automated tests the number of bugs that slips through the cracks will decrease. The mentality of a developer working in an environment where they are being held more accountable and where they see their changes being deployed to production continuously is different from the case where a change done now just sits in the codebase waiting to be released at a (often much) later time.
To sum up I would say CI really is more or less mandated if you have any agile approach. It does not take much effort to set it up, so not having CI is really not an option if you want to succeed with agile. Continuous Delivery on the other hand could be more tricky to set up, although a lot of out of the box cloud based services exists. You also really have to put an effort into automated tests, not only unit tests, but also feature level acceptance tests. There is really just not a possibility to have Continuous Delivery without a suite of automated tests. Once you manage the process of Continuous Delivery and pushing all new changes to a staging environment you are really mostly ready for Continuous Deployment. Continuous deployment should perhaps be the goal for most companies that are not constrained by any regulatory or other requirements. It should not be IT limitations that decides whether or not your company should do continuous deployment, but rather whether it is right for your company based on business needs.