Industry Insights |

Understanding CI in DevOps: Complete Guide

Thinking of the Software Development Lifecycle (SDLC) process of building software, there are a lot of steps including thinking of the idea, designing the idea, understanding how the idea will work, and then building the idea or in other words, writing the code for it. After all of that planning, design, and coding, you have to now think about how youʼre going to begin the “lifeˮ of the code.

That beginning typically, in todayʼs world, starts with the CI process.

In this blog post, youʼll learn about the entire process, what it is, and how you can get started.

Source: https://www.google.com/url?sa=i&url=https%3A%2F%2Fwww.pagerduty.com%2Fresources%2Flearn%2Fwhat-is-continuousintegration%2F&psig=AOvVaw3w8jCyQ13ocFhy8dhndKRC&ust=1737223227949000&source=images&cd=vfe&opi=89978449&ved=0CBQQjRxqF

What Is The “Buildˮ Process

First and foremost, letʼs define what CI is. CI stands for Continuous Integration, and ironically enough, the name justifies its existence. Itʼs a way to integrate code in a continuous fashion. The idea of CI is to constantly and consistently merge an engineer's code from the branch they were working on to a test, build, and confirm phase. Within this “test, build, and confirmˮ phase, code goes through a vigorous process that consists of testing it, ensuring that itʼs secure, and making sure that it wonʼt conflict with code that currently exists.

One of the biggest key aspects of CI is the small batches of code that could get built every week, every day, or every hour. In high performing teams, every time code is pushed to a repository that an engineer is working in, it automatically goes through the test, build, and confirm phase.

💡 The build process isnʼt anything new. You can go back to the 90ʼs during the Netscape days and hear developers talking about building and testing the code. The process as a whole within a pipeline is what became popular in the mid 2000ʼs.

Key Steps

There are a lot of pieces that can make up the CI process. Some of those can include:

Linting
Unit tests
Mock tests
Performance tests
Security tests
Format tests
Compilation of the code (for example, combining to a Wasm binary).

The reason why these steps are so drastically important is because these steps are the only thing sitting in between the code and the destination. After the CI process, the code is theoretically (and hopefully) ready to be deployed to its destination, which is usually Dev, Staging, or Production. If the code doesnʼt go through these vigorous tests to confirm its viability, the destination could potentially be impacted in a very negative way.

💡 Although this blog post doesnʼt cover it, there are two deployment phases - Continuous Delivery and Continuous Deployment. These can happen after the CI phase passes successfully. The process of CI and CD together is called CICD.

Artifact Creation

Before learning how to implement a CI pipeline, one of the key pieces to CI is the artifact thatʼs built. Some call it a package, others call it an artifact or a binary. Regardless of what your team calls it, itʼs the “completed buildˮ of the code youʼre planning on deploying to Dev, Staging, or Production. Itʼs a packaged end state after the code has gone through the CI process which ensures that the code is up to particular standards.

Where Does The Code Come From?

More and more development teams (itʼs almost the default at this point) use Distributed Version Control (DVC). There are a lot of aspects to DVC, but one to understand is the idea of multiple branches. As an engineer, what you can do is create a branch from the primary branch (usually called main) and have it as a completely separate entity. You can build upon it, create features, fix bugs, and then, if the CI process passes, merge that branch into main.

The CI process is especially crucial now as code is coming from all different places and from various teams. It must be tested.

Creating A CI Pipeline

Now that you know a bit about the theory behind Continuous Integration and why itʼs important, letʼs learn how to implement it in one of the most popular CICD tools in todayʼs world, GitHub Actions.

First, under a repo that you have available, youʼll see in Actions button.

Once you click that button, if there are no other pipelines that exist, youʼll be greeted with a plethora of different pipelines to choose from.

For example, if you type in python, youʼll see a list of templates that can be used with Python.

If you donʼt see a workflow that works for you, you can create your own from scratch.

As an example, hereʼs a Python pipeline that does the following:

Builds the code (runs the CI process) when code is pushed to _main.
Ensures readonly permissions
Uses ubuntu as the Runner (a Runner is what runs the pipeline in the background).
Installs all application dependencies via the requirements.txt file.
Runs flake8, a popular Python linter.

If youʼd like to use the code in your own environment, you can find it below.

Although there are several different CICD tools, what you'll find is the majority of them feel very much flush with each other. For example, the majority of CICD tools use YAML to build pipelines.

Closing Thoughts

Continuous Integration (CI) is one of the most important implementations of software engineering and DevOps that you can use. Itʼs quite literally the make or break between the break of your systems. With proper testing, you can get very close to perfect results when deploying software with solid CI processes.

‍

Michael Levan