[ARTICLE]

What is CI/CD? What it means and when to use it.

You may have heard the stories of companies that have abandoned the ‘release cycle’ and push code to production multiple times a day.  This might be a new feature, a small update, or a bug fix. Companies like Google, Netflix and Amazon pushing code to production hundreds if not thousands of times a day.  While the cultural processes of DevOps and SRE (Site Reliability Engineering) play into why this is possible, Continuous Integration and Continuous Deployment (CI/CD) are what are driving the very possibility of rapidly and continuously improving code. 

If you’ve spent any time in the world of software development then you have certainly come across CI/CD.  While the CI, continuous integration, aspect is fairly well understood by software developers as a part of the development process, CD is more mysterious. This may be because it crosses over into the realm of “operations.” The fact that CD may refer to continuous delivery or continuous deployment also adds some confusion.  The image below provides an overview of a typical CI/CD workflow and you can see where the Dev-centric CI process hands off to the Ops-centric CD process.

Continuous integration 

Focused on automating the building of software with testing built into the process, CI is primarily the developer side of CI/CD equation. In the graphic above the flow is to create some initial code (or modify the existing, stored code), run tests on the code, and if the tests pass, update the codebase. This can cycle through multiple times. The stored code – aka “artifact” – could be manually uploaded somewhere to run, but in a world where automation is increasingly the goal, such as in the world of DevOps and SRE, both CD and CD accelerate the deployment process. There are many tools that making support setting up a CI pipeline. Jenkins, Travis, GitLab, CircleCI, and Azure Pipelines are examples.

Continuous Delivery  vs Continuous Deployment

Although these two terms are different, their differences really come at the end of the process, so we’ll come back to that in a minute. The overall CD process is much like the CI process, but now the idea is that testing is going on in the environment that includes any other interactions that will be needed for the final presentation of the code. Especially in cloud systems where API-driven automation the process looks much like the CI process. If all tests pass, the new code is assigned a version and….  Now we need to consider the difference between CD and … CD. Continuous delivery simply means that there is a manual step – a final check- that will release the code into the wild.  Continuous deployment automates this last step with the assumption (recognition) that if the code passes the CD stage tests it is good to go and release into the wild. Like CI, there are many solutions to help you get your CD on – Jenkins, GitLab and Azure Pipelines will be familiar from the CI service examples. Netflix’s open source Spinnaker is also growing in popularity.

When and Why Does CI/CD work?

It is possible to build a pipeline like the one in the diagram and cause a critical failure to occur. The reason that so many companies are confident that CI/CD is the way to go, even in the face of the potential for such failure is that those companies’ DevOps/SRE teams are doing things correctly.

  1. Push small code changes, frequently. This goes for CI and CD.  Version control (and branching dev processes) is certainly going to be part of how code is developed, but those changes should be small.  Many will recommend that whatever you are changing should be ready to push to the master branch at the end of the day. This makes sure that if that change does break something, it should be easy to find and fix.  It also means that what is being pushed (and released) is relevant and you don’t spend weeks on code that suddenly becomes irrelevant.
  2. Build tests. Let me say it again – build tests. Again, a CI and CD principle. Testing the code that is being pushed against automated builds is probably the one thing that gets overlooked in the rush to build something shiny. Not having tests comes with a barrel of regret when it is time to go back and manage when something deep in the code breaks far into the development process. Although strange things will happen, building tests to make sure that the new code behaves as advertised is a first principle of CI processes.
  3. Use both unit and integration tests. More popular on the CI side, but has some relevance to the CD side, especially if you follow the Infrastructure-as-Code model.  You are building tests for your code? They are passing? Good. Now you need to make sure to both build tests that make sure your fancy new feature does what it should, the unit test, and that it plays nice with the rest of the code base, integration test.  
  4. Fix the build before pushing new code. Applies to CI and CD processes. Hopefully this means that tests are failing rather than an actual critical system failure, but the idea here is that you don’t want to pile stuff that could or should work on a system that is broken. This could mean rolling back to a previous version in production, but the better principle is to version forward with a quick fix.  This is the point where you see the value of principles 1, 2, and 3 (you were following these, right?) as small changes should equal small, quick fixes.
  5. Automate all the things. Automation, with testing, will produce systems that are reliably reproducible and avoid the toil of repeating processes manually and potentially adding human error into the system each time. Although this does not imply a static system (see the next point) it does mean that when the code is pushed and passes its tests in the CI system, a functioning and tested CD system should push that code straight through to production with confidence.
  6. Continuously improve the process. Our code lives in a constantly changing environment and as business, security, infrastructure, and other demands change, your system is likely to need to respond.  Because CI/CD is a Dev & Ops process, there are always likely to be places where the process can be improved, simplified and automated further. Having communication across concerns, a core DevOps principle will certainly shine the light on where opportunities for improvement lie. 

Conclusion

Hopefully all this sounds like the way that applications should be built and deployed. This is increasingly a consensus view.  However, while the processes can be laid out and there are multiple tools to support CI and CD processes, it is important to remember that there is a mindset/cultural shift that is required. Going from a waterfall, big release every six or 12 months to pushing code to production multiple times every day does not happen overnight. It is not something that really works if it is partly-adopted.  Even within a single team, having a single engineer not following the necessary testing protocols can derail things.  As when considering adopting any new technology, it is good to start small, start building teams that get the process down, validate how things work for their specific situation and can share their knowledge.  From there it can expand to cover the rest of the company. The CI/CD journey is not one that ends, but rather one that improves, continuously. Contact Opsani to learn more about how our technology and products