Gitlab CI/CD overview

foreword

CI/CD is an approach to continuous software development where iterative changes to the code are continuously built, tested, and deployed. This iteration helps reduce the chance of developing new code based on a buggy or failed version. Using this approach, human intervention can be reduced or eliminated from new code development to deployment.
The methods to achieve continuity are mainly: continuous integration , continuous delivery , and continuous deployment .

Gitlab CI/CD

Gitlab CI/CD, that is, Gitlab, provides the above CI/CD capabilities for continuous integration, continuous delivery, and continuous deployment.
The above Gitlab CI/CD workflow diagram shows the main steps. In actual projects, CI is mainly triggered when the code is submitted or merged, and is responsible for checking some basic rules. If the check fails, then roll back or modify the code before submitting or merging to reduce code risk; CD is mainly triggered manually , on the basis of CI, is also responsible for functional inspection, if the function meets the acceptance criteria, then it can be delivered or deployed.

If you look at this workflow a little further, you can see what GitLab provides at each stage of the DevOps lifecycle:

Pipelines

Pipeline is one of the important components of CI/CD. That is, the pipeline, including:

• Jobs: that is, tasks that define what to do, such as: compiling and testing code;
• Stages: That is, the stage, which defines when to execute Jobs, for example: enter the stage of running tests after the stage of compiling code.

Jobs are executed by Runners. If there are enough concurrent Runners, Jobs of the same Stage can be executed in parallel.

If all Jobs in the same Stage are successfully executed, the Pipeline will enter the next Stage; if any Job in a Stage fails to execute, the Pipeline will not enter the next Stage and end early.

Typically, Pipelines are executed automatically and require no intervention once created. However, it is also sometimes possible to manually interact with the Pipeline.

Generally, the Pipeline contains four stages (stages), which are executed in the following order:

1. A build phase, including a compile job;
2. A test (test) stage, including two jobs of test1 and test2;
3. A staging (pre-release) stage, including a deploy to stage job;
4. A production (production) phase, including a deploy-to-prod job.

Jobs

Job is actually a task, the smallest unit in the GitLab CI system that can be independently controlled and run :

• Defined in terms of constraints, stating the conditions under which those constraints should be enforced;
• Can have any name, but at least contain the script element;
• There is no limit to how many can be defined.

Variables

The environment variables provided for job execution are mainly divided into two categories:

1. CI/CD provides predefined environment variables
2. Custom environment variables

Cache and artifacts

cache is one or more files downloaded and saved by Job. Subsequent jobs that use the same cahce do not have to download the file again, so execute faster. That is, keep the job result

cache：

1. Use cache to define the cache of each Job;
2. Subsequent Pipelines can use caching;
3. Subsequent Jobs of the same Pipeline can use the cache if they rely on the same;
4. Different projects cannot share caches.

artifacts：

1. Define the product of each Job;
2. Subsequent Jobs in the later Stage of the same Pipeline can use the products of the previous Job;
3. Different projects cannot share products;
4. By default, products expire after 30 days. The expiration time can be customized;
5. If "Keep Latest Artifact" is enabled, the latest artifact will not expire;
6. Use dependencies to control which Jobs get artifacts.

The difference between cache and artifacts:

1. Use cache for dependencies, such as packages downloaded from the network. The cache is stored where GitLab Runner is installed, and if distributed caching is enabled, it is installed and uploaded to S3;
2. Use artifacts to pass intermediate build results between stages. artifacts are generated by Job, stored in GitLab, and can be downloaded;
3. Both artifacts and cache define their paths relative to the project directory and cannot link to files outside of the project directory.

Gitlab environment construction

The gitlab environment is mainly divided into two parts, gitlab-ce (manager) and gitlab-runner (executor).

## gitlab-ce安装
sudo apt-get update
sudo apt-get install -y curl openssh-server ca-certificates
curl https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh | sudo bash
sudo apt-get install gitlab-ce

## 修改配置文件, 将external_url改成你可访问的地址
sudo vim /etc/gitlab/gitlab.rb
> external_url 'http://192.168.xx.xxx:6001'

## 重新加载配置，并重启动
sudo gitlab-ctl reconfigure
sudo gitlab-ctl restart

## 查看运行状态
sudo gitlab-ctl status

## 查看运行日志
sudo gitlab-ctl tail

Now it can be accessed through the newly configured http://192.168.xx.xxx:6001.

After GitLab is installed for the first time, what are the administrator accounts and passwords for logging in to the GitLab webpage?

• The account name of the administrator account is root.
• The password is in an automatically generated file /etc/gitlab/initial_root_password (the password will not contain spaces) and is automatically deleted after 24 hours.

## 安装runner
sudo curl --output /usr/local/bin/gitlab-runner "https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-darwin-arm64"

## 授权
sudo chmod +x /usr/local/bin/gitlab-runner

##  使用root,安装并启动
sudo su 
cd ~
gitlab-runner install --user root
gitlab-runner start

## 启动完后注册服务
## 通过 Gitlab项目首页=> setting => CI/CD => Runners => Project runners 获取token
## 填写之前gitlab-ce设置的external_url
sudo gitlab-runner register

## 激活
sudo gitlab-runner verify

Write the .gitlab-ci.yml configuration file

stages:          # List of stages for jobs, and their order of execution
  - build
  - test
  - deploy

build-job:       # This job runs in the build stage, which runs first.
  stage: build
  tags:          ## 加上tag
    - sss
  script:
    - echo "Compiling the code..."
    - echo "Compile complete."

unit-test-job:   # This job runs in the test stage.
  stage: test    # It only starts when the job in the build stage completes successfully.
  tags:
    - sss
  script:
    - echo "Running unit tests... This will take about 60 seconds."
    - sleep 60
    - echo "Code coverage is 90%"

lint-test-job:   # This job also runs in the test stage.
  stage: test    # It can run at the same time as unit-test-job (in parallel).
  tags:
    - sss
  script:
    - echo "Linting code... This will take about 10 seconds."
    - sleep 10
    - echo "No lint issues found."

deploy-job:      # This job runs in the deploy stage.
  stage: deploy  # It only runs when *both* jobs in the test stage complete successfully.
  tags:
    - sss
  environment: production
  script:
    - echo "Deploying application..."
    - echo "Application successfully deployed."

main reference

" A brief introduction to Gitlab CI/CD " "Installing gitlab on ubuntu
" " Gitlab -ci: front-end automated deployment from scratch "