Faster release. Fewer errors. More scalability. It is not surprising that CI/CD is becoming more common. The many CI/CD tools available and increasingly working in the cloud make it logical and relatively easy. Yet there is a pitfall: the organization must be ready. On the other hand, you can always start small and get a lot of results while taking little risk.

CI/CD is a way to develop and deliver fully automated applications. At its core is the automation of manual processes. Not for nothing do CI/CD and DevOps often go together. They can also do without each other, but it makes sense to pair them. After all, DevOps becomes difficult without CI/CD tooling, and DevOps makes CI/CD a lot more relevant.



Many organizations that want to work with CI/CD see advantages such as speed and quality. This is absolutely right: CI/CD allows you to do small releases more often; therefore, the changes are relatively small and there is less chance of something going wrong. Moreover, because all actions and errors are recorded, you are not dependent on the knowledge of specific colleagues. And once everything is automated, it’s much easier to spin up an additional environment for a demo, test or experiment. Finally, shorter feedback loops allow you to make changes quickly and solve problems quickly. Benefits abound.

And then CI/CD is also very broadly applicable. For example, in FinTech, healthcare or government. Industries in which it is often relevant to minimize access to environments. Pipelies eliminate the need for admins to perform all manual steps and for Break Glass / Disaster Scenarios, you can set up admin accounts in advance and set an alert when used. It makes “Keep people away from data” easier.


Those who want to get started with CI/CD do not need to automate the entire pipeline right away. Many companies don’t need it at all, either. Automating part of the process often yields significant gains. What is important, however, is the realization that – even with a partial switch – a certain amount of attention and expertise are important to make it work. Code writing remains essential. Moreover – as with any systems change – the right culture is conditional for success: an organization that is not ready will struggle with CI/CD. It is then especially the CD part that often calls for a culture change. After all, it takes a lot of confidence in the engineers. If every release has to go over thirty disks anyway, and the tuning takes weeks, the speed is immediately lost. In that context, support from management is indispensable.

It is also important that there is room to train and retrain people, if only because development and operations need to know more about each other. But also writing code, building the infrastructure, choosing the deployment strategy, setting up a secure release environment: these are things that require specific knowledge that not every generic developer has by default.


Take the deployment strategy. The choice is wide, with Blue-Green at one extreme: with this you take the least risk, but it is the most complex and costly. This is because you always have two environments running here that you can switch between. As a result, when changes or problems occur, you experience minimal downtime.

The other extreme is working with backups. And there are some variants in between, such as the Canary release. In doing so, you direct one of the traffic to a new version, the other part does not. If something goes wrong, at most half the customers are affected. Relatively easy, but with a bit more risk.

When it comes to mitigating risk, starting small and in-house is recommended. Automate a task that is performed relatively frequently and has many manual components. You thus create a defined entity to practice with. If something goes wrong, your customers won’t suffer. While you do see immediate results. Low risk, high impact. If you have gained some experience, then you can roll it out more broadly.

Sparring with bart about the cloud?