Two developers working in an office
automation testing

What is CI/CD? How to implement continuous development

Posted by Brian Borg on Aug 05 2020

On the acronym front, CI/CD doesn’t inspire as much excitement (or fervent headbanging) as something like AC/DC, but it does have some hardcore devotees in the world of DevOps. Many see the continuous delivery pipeline as the way forward when it comes to deploying new releases and delivering quality software.  

So, what exactly is CI/CD, and why should it inspire excitement (and maybe even fervent headbanging) in software developers? Put simply, it’s a DevOps strategy that makes frequent software updates possible. Here’s what those letters mean, and the basics of implementation. 


CI: Continuous integration

The ‘CI’ in CI/CD stands for ‘continuous integration’. The goal of CI is to encourage frequent updates from developers. The changes are automatically built, tested and reported on as soon as they are pushed to the code repository. 

The approach makes it easy to catch problems while they’re still manageable. Instead of a massive backlog of bug fixes to address, developers get an instant report as soon as they’ve submitted their code. Changes can be made far more frequently, without risking a dip in software quality. This is the fundamental benefit of CI/CD. 

 

Continuous testing

Continuous testing makes CI possible. Developers or QA professionals establish automated tests for each feature that’s worked on. These are then automatically executed at pre-defined triggers - for example when the developer checks in new code, creates a new build, or when a build is pushed to a new environment. 

 Getting the automated test scripts in your CI process right is essential. Flawed tests will open the floodgates and bugs will pass through to delivery and deployment unaddressed. They could also cause false positive bug results that will have your developers head banging their desks, rather than the air.

Unit tests – those that focus on individual features or functions – are the natural place to start, because they don’t deal with as many moving parts. Once you’re confident in these (or if you’ve hired testing professionals) you can move on to more complex tests and supercharge your CI process. 

New call-to-action
CD: Continuous delivery (or deployment)

CI initiates the process that is carried out by CD, or ‘continuous delivery’. In short, CD means that you’ve automated your release process as well as your builds and tests. It kicks in when code changes have passed through the CI gauntlet. 

By automating the release process, those frequent fixes and updates that developers are able to make get added to the production-ready software in a matter of seconds. It eliminates the need for major releases or release day sprints.


Continuous deployment

Continuous delivery requires a bit of manual intervention because the pipeline waits for a ‘go-ahead’ before making changes public. Continuous deployment – the other version of ‘CD’ – eliminates this manual step.  

As soon as a developer pushes a change to the code repository and it passes through the CI process, the change will be made to the software and a new version will be deployed. You can set these updates to release on a more controlled basis – once a day, for example – but the idea is the same. From commit to deployment, everything is automated. 

When it comes to adopting CI/CD, it’s probably best to go with the ‘delivery’ definition (requiring a manual ‘go-ahead’) at first. The reason? You have to be incredibly confident that your testing is watertight if you’re using continuous deployment. If anything goes wrong, a bug will find its way to your users before you’re able to react. It’s for this reason that some make use of ‘feature flags’. 


Adopting continuous development

Implement CI/CD slowly and steadily. The significant efficiency boost it offers can lose its appeal if you’re finding that bugs are increasingly finding their way to your finished application. Perform unit tests at first, manually trigger releases, and consider working with QA engineers for some deployment peace-of-mind. 

We’ve just scratched the surface when it comes to the benefits of a continuous development approach. It’s a broad, complex subject, but you should now have a better idea of what it means and the components that make it work. 

 
New call-to-action
automation testing continuous integration continuous deployment continuous testing continuous delivery best practices