Basic CI/CD Terminologies you should know!

Introductory for new starter about CI/CD

Photo by Andrik Langfield on Unsplash

Do you recognize yourself…? You just got your university degree in computer science (or whatever) and start working in a tech company. Soon you realize that despite all the theoretical knowledge and few group projects you don’t even know the basic tools and workflow of professional software development. It’s a bit like the situation after school, where you still don’t know how to do your own tax declaration.

I had to make this experience as a beginner in my first job. When I started I never heard anything about CI/CD or I didn’t really have a complete understanding of it until now. Of course, you have learned something about testing and quality of software in your studies and you have heard how this software is released but it was not enough for the real world. Now arriving at the first job I was confronted with the terms webhooks, runners, pipeline, stages, build processes, release, etc., and didn’t know how to deal with them. All these terms can be found on well-known code hosting platforms like GitHub or Gitlab. For your professional career, I think it is important to know how these terms and concepts are related. Some of these terms are even completely identical in meaning and yet you think they are different. In the following, I want to help you to better understand these terms.

This article is only about the concept and related terms of CI/CD and a follow-up post will cover the automation of CI/CD.

Let's start first with the concept of CI/CD. What the heck is this?

CI/CD stands for Continues Integration and Continues Delivery. These are actually two workflows tightly coupled to release or deploy software. Besides Continues Delivery, there is even another “CD” which stands for Continues Deployment (but first we stick with Delivery). Within CI/CD, one would like to achieve two goals:

1. One can deliver changes to software at any time bug-free ( this article is about)
2. The delivery of the changes is completely automated. (next article)

Here you can directly assign the two workflows CI and CD. CI is responsible for testing the source code and CD is responsible for the corresponding delivery of the tested source code. Now let’s take a look at the tasks in CI and CD of a CI/CD Pipeline in the following figure. In some platforms, the tasks are also called (like in Gitlab) stages. Disclaimer: Some might say that “Build” is a part of CI, but this is discussable. I will stick with the figure.

CI/CD Pipeline (by author)

Tasks in Continues Integration (CI)

CI is all about the source code which has to be integrated into an existing source code. The source code (changes) is put through its paces. You can imagine the tasks as being like a security check at the airport, which you have to pass successfully in order to get to your flight. So CI verifies the quality of your code changes, ensuring it is safe to deliver them.

• Linting: Here we are talking about the static analysis of the source code. This means you are not executing the source code. It is responsible to identify common programming and style errors.
• Unit- and Integration-Test: Here all old tests and new tests are run through to see if everything still works. ( I am assuming you know what these tests are…)

If the source code still works and no test errors are reported, then congratulations your changes have been integrated. After these tasks, the source code is in a releasable state.

Tasks in Continues Delivery (CD)

Here it is all about releasing the new changes of the source code. Instead of checking the code, it is now much about transforming the source code into a form so that it can be released. CD is related to the following terms:

• Build: All source code and other artifacts (e.g. images, text, etc.) are collected and put into a specific form. The form depends on further use. Mostly it usually means compiling the code written in a programming language into a machine language.
• Publish: You publish your changed application (source code) by copying it to a software repository. This is a repository that contains all tested and published versions that are ready to be released. An example is uploading an image (e.g. Docker image) of the changed application to an image registry (e.g. Docker registry — Docker Hub.).
• Release: This is the part where you make your changes available to the user. The changed application gets traffic here for the first time (e.g. by replacing the previously running image with the new image)

I know that the terms “Publish” and “Release” are semantically very close. I had to choose the terms so that you can better place the concept of registries.

Conclusion

So that’s it for today. So far, the most basic terms have been introduced, which will certainly help some people to better understand the concept of CI/CD. With this pipeline, we achieve the first point of the two goals introduced at the beginning. Next time, let’s see how this pipeline is automated. Then the terms webhooks, runners, etc. will be covered.