Demystifying Acronyms Part Two: CI/CD Explained

People often picture programming as dark screens full of green code, typed at surreal speed. That is the Matrix, not real life. As a front-end developer, I agree that a lot of the job is writing code. But this article is about what happens around the code, in the world of DevOps. In short, it is about CI/CD.

A CI/CD platform is a set of tools that help developers, engineers, and DevOps teams package and ship software to end users. Let's walk through a project's pipeline to see what Continuous Integration (CI) and Continuous Delivery or Deployment (CD) really mean.

How CI fits into an agile workflow

At Wolfpack Digital, we use the Scrum framework as part of an agile process. We break work into small, shippable pieces. That way large projects move forward while the team keeps delivering value to customers on a regular basis.

Instead of building features in isolation and merging them at the end, each developer integrates code into the shared repository many times a day. Continuous Integration is the build and test stage that runs automatically when a commit lands on the main branch. With CI, code changes are built and tested on their own, so the code stays ready for a release to production.

The build stage automates developer contributions and standardizes software quality and environments. This makes bugs easier to fix and shortens the time to validate and release updates.

After a successful build, the test stage runs automated unit and integration tests to give you the widest test coverage possible.

Next comes CD. Continuous Deployment extends the automation: software ships after every commit that passes the test suite, with no human step. Continuous Delivery stops just before that, keeping the software ready to deploy while humans decide if, when, and where to release.

Source: Continuous Integration (CI) Explained

Each stage in the pipeline acts as a gate that checks one aspect of the code. A problem found early stops the code from moving further. There is no point running the whole pipeline if a fundamental bug needs fixing first. When a gate fails, detailed logs go straight to the team so they can fix it.

Setting up a CI/CD pipeline with CircleCI

There are many CI/CD platforms to choose from, such as GitHub Actions, GitLab CI/CD, Jenkins, and CircleCI. GitHub Actions has become a common default, but each tool has its strengths. For this walkthrough, we will use CircleCI on a Nuxt.js app. I will assume the repository is already linked to CircleCI. If not, check the documentation for the setup steps.

The config.yml file

CircleCI connects to your project through a config.yml file inside a .circleci directory. Once your repo is linked, the projects page shows a "Set up project" button. From there, CircleCI offers pre-defined config.yml templates you can use as a starting point.

From the sample templates, I chose the "Hello World demo" option. It created a demo config file with a "Commit and run" button. That pushed the file shown in Fig. 1 to my repository. The CircleCI dashboard then showed the first workflow, with the predefined "say-hello" job.

The best way to understand this YAML template is to read it line by line and see what each concept means.

Fig. 1 - generated config.yml file

Fig. 2 - CircleCI dashboard

A. Workflows

Think of workflows as the part of the YAML file where everything comes together. In the example, a workflow has a name and runs the "say-hello" job declared in the jobs section. A workflow holds one or more uniquely named jobs and controls the order they run in. Jobs can run concurrently, in sequence, on a schedule, or behind a manual approval gate.

B. Jobs

Jobs are the building blocks of your configuration. Each job is a collection of steps that run commands or scripts, executed as a single unit in an execution environment. Every job must declare an executor: docker, machine, windows, or macos.

C. Steps

The steps section is a list of commands needed to complete a job.

Before your workflow can do anything with your code, it needs the code. The built-in checkout step handles that: it pulls the code from your repo so the pipeline can work with every file. After checkout, the shell commands under run execute, and the results appear in the CircleCI dashboard, as shown in Fig. 2.

Now that we have covered the terminology, let's adapt the config.yml file to add a job that runs a lint check with prettier and eslint on every new commit.

Fig. 3 - lint job configuration

Assuming the packages are already installed, I added a lint job that uses a pre-built Node.js Docker image maintained by CircleCI. This lets us run the shell commands defined in package.json, such as yarn lint. The steps start with the default checkout step, then two named shell commands that run in sequence.

Fig. 4 - CircleCI job view

I committed the changes, and the output shows the step titles from the config, followed by the terminal output from the commands. Now for the fun part: let's break something to see how the pipeline reacts.

I ran yarn remove eslint to delete the package and show how the lint step behaves without it. A failed workflow now appears on the dashboard, and the failed job looks like this:

This walkthrough covered only the basics of CircleCI, but the platform can do far more, such as:

CI/CD in a nutshell

To wrap up, here are the main benefits of CI/CD practices:

Continuous Integration kicks off after a developer checks code into the repository. It runs lint checks, builds, and unit or integration tests.

Continuous Delivery packages the software artifacts from CI and gets them ready to ship into an environment like QA, UAT, or production.

Continuous Deployment pushes that packaged software into one or more environments without any human step. In practice, that means adding another shell command for a deploy job in the config.yml file.

Researching CI/CD can feel uncomfortable, but it is a necessary step for any developer. Bash scripts may not be your favorite, but they help you see what runs beneath the beginner-friendly frameworks, which are only a small part of a senior developer's work. Want a team that ships with solid CI/CD in place? Explore our web development services.