CI/CD

Translated from German using DeepL.

Date: February 2023
Reading time: 4 minutes

After reading this blog post, you will know what CI/CD is and how it can be implemented in projects.

What is CI/CD?

Continuous Integration / Continuous Deployment is a process in which code is regularly and automatically tested, built and placed on a repository or even a production environment. repository or even a production environment.
Automation ensures that the code is error-free at all times. In addition, a lot of manual effort can be saved during deployment can be saved, as the necessary steps can be carried out automatically.

In the following lines, I will describe how this concept can be used with GitLab.

.gitlab-ci.yml

The .gitlab-ci.yml file is the CI/CD configuration of a project. The file defines the pipelines, jobs and environments. It is stored in the root of the repo/project.

Stages & Jobs

A job is a single task. It is nothing more than a script that is executed under certain conditions and in a defined environment. is executed.
A stage is a section that holds grouped tasks/jobs. The stages define in which order which types of jobs are executed.

stages:
	- test
	- export
	- deploy

test-job:
	stage: test
	image: cypress/base:16.17.0
	script:
		- echo "Running tests..."
		- npm ci
		- npm run test
		- echo "Tests done."

Restrictions

Jobs can be configured so that they are only executed for actions on the master, for example.

only:
    - master

Artifacts

As each job is executed individually, you initially have no access to the results of the previous scripts. However, you can use artifacts to transfer outputs to the to the next job.
For example, you can export the project in one job and deploy the result of this export in the next.
This is described in more detail here: https://docs.gitlab.com/ee/ci/pipelines/job_artifacts.html (opens in a new tab)

Variables

In CI/CD, variables are not only good for storing recurring values, but also for protecting passwords and user names.
This is because such sensitive data must not be placed visibly in the script.

Variables can be defined on GitLab.

These can then be used in the code with a dollar sign: $PASSWORD

Runner

To be able to use the .gitlab-ci.yml file described above, you need a runner. A runner is an external machine that can execute the can execute the code.
When creating a runner, you can choose which infrastructure/platform should be on it.

These are the features of the runner: https://docs.gitlab.com/runner/#features (opens in a new tab)

Specific Runner

There are two ways to use runners. One is to use a specific runner. This involves creating your own runner on a system.

# Download and install binary
# Download the binary for your system
sudo curl --output /usr/local/bin/gitlab-runner https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-darwin-amd64
 
# Give it permission to execute
sudo chmod +x /usr/local/bin/gitlab-runner
 
# The rest of the commands execute as the user who will run the runner
# Register the runner (steps below), then run
cd ~
gitlab-runner install
gitlab-runner start
 
# Command to register runner
gitlab-runner register --url https://git.namics.com/ --registration-token $REGISTRATION_TOKEN

You will be asked for an executor during setup. The code is then executed on the executor.

Shared Runners

The more common variant is to activate the use of shared runners. Shared runners are runners that are shared across the entire GitLab instance. are shared.
To execute the Yaml file, a suitable runner from the pool is used.

Docker image

The scripts from the Yaml file are usually not executed directly on the runners. Usually, with the help of a Docker image, a suitable environments are defined.

A Docker is basically a virtual machine whose configuration (systems and versions) can be defined. This guarantees that the code is executed in a consistent environment. This uniform environment is particularly advantageous for test processes.
And if not all members of a development team use the same operating system, Docker can also be the solution.

A Docker image is a definition that is used as a guide for building a Docker container. It specifies what the container must have for specification must have.

Example

I have a project that runs on Node 16.17.0. Now I want to automatically deploy it to the master during the merge.
Of course, I could install a node version manager in the export script on the runner and use it to read, download and use the node version. use it. But this quickly becomes complicated. And if you want to carry out tests beforehand, you may need additional environments. The easiest way is therefore to specify an image for the scripts. This allows you to execute the commands directly on the desired environment.
Another advantage of this procedure is that you can use the same environment for several scripts.

All images can be found here: https://hub.docker.com/ (opens in a new tab)

Possible applications

To give you food for thought, here are three of the possible uses of CI/CD:

• Builds & Deployments: Automating these processes saves time. Errors can also be avoided.
• Testing: Code quality and security can be ensured with every push/merge/deployment.
• Monitoring: Scripts can be used to automatically monitor the performance, error messages and security threats of an application. automatically. This allows problems to be detected more quickly.

Conclusion

With a good CI/CD setup, tasks can be carried out reliably and automatically.
It therefore makes perfect sense to create such a script. Because in the long run, it saves a lot of time and work.