Why it's, still, a good idea to separate CI and CD in Software Delivery

The last thing you need is another tool to manage…another “thing” to set up, configure and maintain from this day onwards. Why can’t we just use our current CI…CD whatever it is and have that one cover the extra requirements that the Dev Team requested?

Not a solution

This is a common thought among DevOps Engineers, especially due to the fact that most have some experience with maintaining tools, servers, and systems or, in some cases, actually have a background as a SysAdmin. So, reducing the number of tools is a reflex to most of us, now why is not a solution in this case?

Well, the short answer would be the complexity of maintaining two tools now becomes double the complexity of maintaining one. Worst, you have an integration tool doing continuous delivery, even though that tool was only built to do continuous integration. Tools are built with specific purposes, to solve specific problems in determined situations. So, the tool should be maximized to solve those specific problems, not adapted to solve multiple problems in situations that do not match their purpose.

CI vs CD

The specific problems that come to my mind, that are specific to CI and CD, in most cases, are verifications.

Code testing vs App performance testing.

In CI you will usually find your unit, regression and integration testing. These are specific to optimize code among multiple commits and on the work of multiple devs on a singular repository. A CI tool will also focus on integrating with multiple code securing tools or code vulnerability scanners. The purpose of CI is to test and scan code early and often to ensure that only safe and optimal code gets to be compiled/built into an artifact.

CD, on the other hand, focuses on taking your artifact to your users. At this stage, you focus on moving your deployments through your environments, Dev to QA to Prod, and verifying performance and functionality as much as possible. You also want to take your change control tools into consideration here as well as you want to log all your changes and deployments, especially in Production. Speaking about deployments, this would be a good time to also use your CD tool to set up a corresponding release strategy for your App, whether it’s rolling deployments, blue/green or canary.

So, as you can see, there are big differences between the problems that CI tools solve and the ones that CD tools solve.

route and is more around change control moving your artifact from dev to staging to prod and around the performance and functionality of your app.

Closing Thoughts

Multiple tools, in this case, should mean more features, especially if you orchestrate your tools accordingly. Focus on integrating your tools with each other, this way you will streamline your integration and deployment processes. Make sure your CI tool is able to integrate (I know, intentionally written :smiley: ) with your code testing toolkit and with all the necessary repos for your final artifacts.

As for the CD tool, make sure it can use your APM and Logging solutions to monitor and verify your deployments. Also, ensure it can orchestrate your infrastructure and adjust it accordingly for your apps. And, of course, that it can easily navigate your on-prem, cloud or containerized environments and that it can handle all required types of deployments.

This way you will be able to use the tools and the development process to your advantage …you’ll have your tools take the orchestration pain off your shoulders as a DevOps Engineer. You’ll also allow the development process to evolve by itself and simplify your Devs’ job too! You’d have moved to a more DevOps mindset and become more agile! And most importantly you’ll Get Ship Done!

1 Like