Continuous culture for CI/CD

So far, I feel that you have noticed that we haven't talked about any tools to make DevOps possible. This is because tools will not solve all these types of problems. They will help you and your customers enforce the DevOps culture, but they are not what makes DevOps possible.

Standardization and testing before we deliver our product is essential to Agile and DevOps, and tools will help us achieve these two goals. Let’s take a look into the Agile workflow and the DevOps workflow:

Here is a look at the Agile workflow:

Here is how it compares to DevOps:

It is very clear that both go hand in hand and that they overlap each other, as they seek the same goals. DevOps has extra steps, such as operate and monitor, which take place after the deployment of the code. These steps are very self-explanatory; monitor consists of monitoring our application in production, checking its behavior regarding whether it presents any bugs, of whether it is using all the resources that were allocated to it. Operate the hardware, VM, or PaaS where it was deployed.

The idea behind continuous deployment (CD) and continuous integration (CI) is to bring us standardization and the means for us to make sure that changes and releases make it into production as quickly as possible with the least possible failures. If a failure happens, we can revert quickly and easily as well. The whole point of CI/CD is to automate manual processes, and many companies still compile releases manually and still send emails to operations with the binaries and instructions on how to deploy their code. To achieve CI/CD, we have tools that will help us automate the whole build, test, deploy, and release cycle.

A typical pipeline of CI/CD is triggered by a commit to a Git repository, which then triggers an automated build process that usually generates an artifact or a drop, which triggers automated testing and automated deployment of the application.

Let's take a look at some of the different open source tools, with a brief explanation of each and to which stage of the DevOps cycle it belongs to.

This is nowhere near an extensive list, and the explanations are a brief summary of their purpose: