Breaking Down CICD In A DevOps World

#devops #cicd #softwaredevelopment #engineeringmanagement

CICD is of course one of the most popular DevOps-centric tools in today’s world, yet it’s not as new as people think. Underneath the hood, CICD is simply an orchestrator.

Do a thing for me at scale

In this blog post, you’ll learn all about how to get your mind wrapped around CICD, and hopefully, you’ll come out the other side knowing that you can jump into it at any time and that it doesn’t take much to figure out.

Continuous Integration

When thinking about Continuous Integration (CI), I want you to think of a present. Let’s go with a toy chest.

When you buy a toy chest from the store, you have to probably put it together. Use a few nails, some screws, and some power tools. Once you put the toy chest together, you have to wrap it so someone can open it.

That’s Continuous Integration.

CI is the process of taking code (the toy chest), putting the code together (like putting together the toy chest), and packaging it up for later use (like when you wrap the toy chest).

Code that’s running through a CI process is typically in source control. The code gets packaged up and turned into some type of artifact that’s later used in the CD process.

CI is nothing more than taking code and putting it into a mythical folder for later use.

Key Aspects Of CI

There are a few key things that happen during the CI process besides building the code.

The first is the testing of the code. Typically, you’ll see that unit tests, integration tests, etc. are run at this stage. The reason why is because there’s no reason to build code if it’s not going to actually work.

Security checks from a code perspective are also run at this stage. Perhaps something like SonarQube or some security-based linter runs against the code.

Continuous Delivery and Continuous Deployment

In the previous CI section, remember when you learned about the whole take a present, wrap it, and that’s the CI bit?

Let’s take that same present example.

Once the toy chest is put together and wrapped, you now need to give it to someone. You maybe need to drive it to their house and put it on their doorstep.

You need to deliver it to them

That’s Continuous Delivery and Continuous Deployment (you’ll learn about the distinction between the two coming up shortly).

CD is the process of taking the code that runs through the CI process and deploying it to whatever location. That location could be a virtual machine or something in the cloud or even a container. Essentially, it’s any destination that you’re able to deploy code to.

You can even deploy Terraform code to build a virtual or cloud resource, so it doesn’t necessarily have to just be application code.

CD is nothing more than taking code and putting it somewhere.

CD and CD - There’s A Difference

There’s a huge distinction between Continuous Delivery and Continuous Deployment.

Continuous Delivery deploys the code automatically, but with a little human intervention. You can automatically deploy the code, but someone has to press a magical button on the CICD platform for the code to actually be deployed. If no one presses the button, the code won’t be deployed.

Continuous Deployment takes Continuous Delivery a step further. Instead of having to press a magical button to deploy the code, it just runs as soon as the CI process finishes. Whether it’s at 2:00 AM or 2:00 PM, the code will be deployed automatically with zero human intervention.

Why CICD Is Important

Think about what you have to do if you don’t use CICD.

First, let’s start with the CI process. You have to:

Manually build code
Manually run tests
Manually create artifacts

Now, let’s think about CD. You have to:

Manually SSH or RDP into servers
Manually copy/paste code to a server
Manually run it

That’s a lot of manual steps.

The reason why CICD is so important isn’t that it’s a new and hot technology; it’s because CICD is crucial to how we deliver software and infrastructure code. Engineers can no longer work through manual processes in hopes of just doing the same thing over and over and expecting different results. Engineers have to create repeatable processes so they can focus on more value-driven work vs putting out fires all day.