The Benefits of Continuous Integration/Deployment & Delivery
5 min read
At Cantarus we’re firm believers in Continuous Integration (CI) and Continuous Deployment, and also strive to use Continuous Delivery (CD) where it makes sense to do so. Before launching into listing all of the wonderful advantages and benefits of these approaches, it is worth defining each term as, confusingly, they are often used interchangeably.
Continuous Integration (CI) is the practice of regularly merging, building, and testing developers’ code together in a shared branch. Traditionally these activities were carried out in the form of a nightly build, during which developers cowered in fear as they waited to see if their code that broke the build or worse yet an unknown error in someone’s code causing a Mexican standoff over the coffee machine the next morning. Thankfully, for both operational efficiency and the preservation of office friendships, improvements to source control systems and the reduction in cost of computing resource has allowed code to be integrated and tested immediately on each merge request.
Continuous Deployment is the process of automatically deploying changes to a system once they have been integrated and tested. This can either be to a live system used by end users, to a test system or staging environment that can be used by manual software testers or demoed to other stakeholders. The ability to make use of continuous deployment depends on whether it is supported on the platform on which it is being developed. In the case of the DNN platform we developed PolyDeploy for this purpose and donated it to the DNN open source community.
Last but not least, Continuous Delivery (CD) describes the overall culture, methodology, and process of delivering changes into the hands of end users as often as possible. Under CD, development work is packaged into small chunks that aim to keep the software in a shippable state at all times. The end goal of CD is to ensure that each and every merge request contains an entire shippable feature that is automatically deployed when the merge is accepted and all required tests are passed.
All three of these concepts come under the umbrella term, Continuous Development (yes, there could have been room for more imaginative titles).
Adopting continuous development can be a culturally-jarring experience for your organisation and requires an entirely different mindset from your developers, testers and managers for successful implementation. However, if managed correctly, Continuous Development enables organisations to reap several benefits:
Increased Code Quality
In our own experience, we found that continuous development leads to an increase in the quality of the products and services that we are delivering. This improvement in quality is caused by several factors:
- Smaller and more frequent changes encourage developers to create more modular code that is easier to test and maintain;
- Constant integration testing catches bugs and issues early, usually before they are deployed;
- Stakeholders and users can provide feedback quickly to ensure that the development team are on the right path rather veering aimlessly towards a solution that no-one asked for.
Continuous development allows developers to focus on smaller items that tend to be completed faster than larger chunks of more general work. Coupled with streamlined testing and a quick feedback loop, this means that developers spend less time debugging issues and more time building shiny new features.
Without continuous development, bugs are raised during the UAT phase days, weeks, or even months after the developer first made the change. Of course, over time, the developer might not be quite as familiar with the code they originally submitted. Furthermore, the line of code that is causing the issue could be hidden away under months and months of work – not an ideal situation. However, if you were to let the wonder of continuous development into your life, any issues would be raised immediately (in the case of automated testing) or within a few hours (via manual testing) – meaning that the developer only has to search for the bug in a small change set rather than the mountain of code that would be otherwise presented.
Accelerated Time to Market
If your organisation can reduce the time between coming up with a knockout idea and the implementation of said knockout idea, you will be much more adaptable to changing market demands, enabling you to stay one step ahead of the competition.
The larger a release of a software product, the greater the risk and cost of failure. Unfortunately, by increasing the number of features included in a release, you also increase the likelihood that these features will be non-functional, irrelevant, disruptive or disliked by users.
Nobody wants their software release to be the equivalent of a ‘New Coke’ or ‘Windows 8’ (and most other even-numbered iterations of Microsoft Windows for that matter, including Vista), creating a PR disaster by moving further away from what the customer wants or needs. Fortunately, the short feedback loop provided by continuous delivery ensures that these types of problems can be easily avoided.
Humans hate change. We decide that our way is the best way to do something, simply because that’s the way we’ve always done it. This remains the case even when the new way gives users features that they actually want. Take large online platforms like Facebook and YouTube, for example - there is invariably an emphatic but short-lived backlash to every major change to the look and feel of these sites. However, by releasing new features on a regular basis, you can limit the ‘short sharp shock’ of change felt by the users, perhaps to such an extent that they may not even notice it all…
From a development process point of view, larger releases pose a much higher risk of exceeding time and budget constraints, or ending up in ‘UAT Hell’ (passing a large release into User Acceptance Testing and finding that hundreds or thousands of issues are raised).
If a release does fail, it happens to everyone sometimes – don’t worry about it, it is much easier to rollback a small number of changes than a large release with lots of wide-ranging features. It is also more likely that flaws will be picked up quickly in a small release than a large one – like finding a needle in a haystack rather than in a stack of needles.
Finally, large releases place a massive amount of strain on your staff, both in terms of an increased likelihood of overtime in crunch time and the general stress of trying to get as much as possible into a single release.
Stressed-out developers, and people in general, tend to make more mistakes - especially if they’re also in a rush. This usually means a drop in quality during the final phase of the project that is usually set aside for applying polish.
As you can see, there’s a lot that continuous development can offer. It allows you to provide a higher volume of better-quality code more often, reduce risk and maintain staff and customer happiness. If you would like to learn more about continuous integration and implementing it within your business, drop us an email at [email protected]