CI/CD, SDLC, and other concepts in the DevOps culture

Author:
Innokrea Team

Date of publication: 2024-03-28

Caterogies: Programming

Today we’ll try to introduce you to the matter of CI/CD and prove to you that its implementation increases teams’ efficiency, as well as the frequency and quality of software deployments in your companies. We’ll also talk about what blue-green deployment and single source of truth are. If you’re curious, we invite you to read on.

What is CI/CD?

We expand the acronym as continuous integration/continuous delivery/deployment. The first part of this acronym refers to the integration of code into a shared repository, which is a commonly practiced technique in almost every company involved with software. For this purpose, developers most often use GIT software and a remote repository like GitHub, GitLab, or Bitbucket hosted by themselves or a publicly available version on the internet. Continuous integration refers to frequent committing of code changes by developers and pushing them to the remote repository. Additionally, DevOps practices such as automated testing and building (build) the project in case of passing the tests are included in CI. In case of a code error detected by tests, the developer promptly receives feedback on the failed tests. Additionally, we ensure that the main branch of our repository, i.e., main or master, contains a fully functional, tested version of the software. It is not possible to merge branches if the changes have not passed the tests.

The second part, CD, can be developed in two ways – both as continuous delivery and deployment. The former means automatic deployment to the testing environment, often called stage. After such deployment, manual intervention by a responsible person is required to deploy the built version to the client. If we also automate the last step, i.e., deployment to the client, then instead of continuous delivery, we talk about continuous deployment.

Figure 1 – CI/CD process, source: synopsys.com

How does CI/CD relate to SDLC?

Recently, we told you about the different phases of software development within the SDLC (software development lifecycle). If you’re not familiar with the topic, we recommend checking out our article, which we published a few weeks ago.

But what connection does CI/CD have with SDLC? Well, the individual phases of software development utilize DevOps tools (including CI/CD) to accelerate code production, increase automation, and consequently enhance the overall efficiency of the company. During the software development phase, we commonly use version control systems (usually GIT), which, as known, relate to the CI phase. On the other hand, software testing during SDLC can be classified under both CI and CT, i.e., continuous testing. Deployment in SDLC corresponds to all CD tools, such as continuous deployment, for example, Jenkins, Github Actions, or CircleCI. Within SDLC, we also distinguish maintenance and monitoring, referred to in the DevOps culture as continuous monitoring, as one of the final stages. Here, tools such as Prometheus or even Zabbix can be mentioned, allowing for the aggregation of system information and its graphical presentation for the administrator.

What are SSOT, blue-green deployment, and rollback in DevOps?

To better grasp the context of DevOps culture and CI/CD, it’s worth understanding a few concepts that make systems more reliable and efficient. SSOT (single source of truth) is a concept that involves having consistent, authoritative information in one place, a data source. This helps maintain a defined version of a particular software or file and is often used in the context of DevOps, for example:

GIT remote repository – serves as a single source of code and configuration files for CI/CD software.
Documentation – there should be a single, version-controlled (often within GIT) documentation for a given system and should be updated with the changes being made.
Infrastructure – in DevOps, we often use IaC (Infrastructure as Code) tools like Terraform to declaratively define the state of our servers. Such configuration, also version-controlled, then becomes a single point of knowledge about our infrastructure.

Another concept worth knowing in DevOps discussions is the so-called blue-green deployment, which refers to a duplicated infrastructure, for example, a server that we use. The blue environment refers to the currently running version of the application, and the green one refers to the newer version that we will be deploying. The green environment does not receive any traffic from clients. When we deploy the application to the green environment, traffic from clients is gradually or entirely redirected to the new environment.

Figure 2 – blue/green deployment, source: candost.blog

If only a portion of the traffic goes to the new environment, such deployment is called a canary release. This helps avoid the potential risk of depriving users of the service in case the application malfunctions. Monitoring the traffic from canary releases can also help detect potential application errors. If the deployment completely fails (whether it’s a canary release or a full deployment), modern DevOps systems allow for a rollback, i.e., reverting to the last working version. In the case of blue-green environments, this can be done with just one click by redirecting traffic back to the blue infrastructure.

There are advanced tools like GitLab that allow for an integrated environment for managing both remote GIT repositories and deployments or rollbacks. The exact configuration of the environment depends on technological choices, costs, and the needs of the company.

Summary

We hope that today’s article has brought you closer to the concepts within DevOps. To understand the work of a cloud engineer, SR, or DevOps, it’s essential to grasp the basic concepts to navigate through a large number of acronyms and concepts effectively. If you’re interested in DevOps, we recommend our previous articles on Docker best practices and Terraform, which we link as sources. Join us next week!