A, definitions,

Continuous integration is a software development practice in which team development members frequently integrate their work (merging code onto a common branch) by integrating each member at least once per day, which means that multiple integrations may occur per day. Each integration is verified by an automated build (including compilation, release, and automated testing) to catch integration errors early.

Second, the benefits

1, reduce the risk, integrate every day and every integration through the corresponding test, can be relatively rapid positioning error 2, prevent branch greatly deviated from the main branch, difficult to integrate 3 late, reduce manual code duplication of work 4, enhance the visibility of the project, project members can understand the project situation, is conducive to teamwork

Third, integration tools

There are many integration tools. This article introduces GitLab CI

GitLab CI is a built-in tool for continuous integration of GitLab. It only needs to create. Gitlab-ci. yml file in the root directory of the warehouse and configure GitLab Runner, and GitLab will automatically recognize. And the script is executed using Gitlab Runner.

GitLab CI is composed of the following two modules: Gitlab-CI Server, which is responsible for scheduling, triggering Runner, and obtaining returned results, and Gitlab-Ci-Runner, which is mainly responsible for running automated CI (test, compile, package, etc.).

Gitlab Runner is a tool used to execute. Gitlab-ci. yml script, which can be understood as gitlab-CI is like the management center. Runner should first go through the entry procedures (registration) and explain which project he is in charge of when the corresponding project changes later. Gitlab-ci notifies the corresponding runner to respond to the change (that is, execute the corresponding script).

Gitlab-runners can be divided into two types: Shared Runners: those that are available to all projects and can only be created by system administrators. Specific Runner: Only Specific projects can be used.

Iv. GitLab CI practice

1. Install Runner

Runner Installation procedure (Linux) :

/ / download curl - LJO https://gitlab-runner-downloads.s3.amazonaws.com/latest/rpm/gitlab-runner_ < arch >. The RPM/RPM -i/installation gitlab-runner_<arch>.rpmCopy the code

For other system installation, refer to the official documentation

2. Sign up for Runner
gitlab-runner register
Copy the code

Enter the URL and token of Gitlab, enter the GitLab repository, click Settings -> CI/CD on the left menu bar, and expand the Runners Settings to find the corresponding URL and token. Enter Runner’s description, tag, and platform (shell in this case) as prompted. After registration, you can find the newly created tag in the URL and token address of Gitlab.

3, gitlab – ci. Yml

After the installation and registration of Gitlab-Runner is completed on the server, we need to create a.gitlab-ci.yml file in the root directory of the project, and the.gitlab-ci.yml file defines the operations of Gitlab Runner. The basic example is as follows:

# define job dev-job1: stage: dev only: refs: - /^dev$/ variables: - $CI_COMMIT_MESSAGE =~ /\-\-build/ script: - echo "I am the dev job " - sh xxx.sh tags: -dev # create job sit-job1: stage: sit only: refs: - /^sit$/ variables: - $CI_COMMIT_MESSAGE =~ /\-\-build/ script: - echo "I am the sit job" - sh xxx.sh tags: - sitCopy the code

stages

Each commit pushed to Gitlab generates a pipeline associated with that commit. If a push contains multiple commits, the pipeline is associated with the last commit. A pipeline is a collection of jobs divided into different stages. A pipeline is like an assembly line. Each assembly line has many stages, and each stage has corresponding tasks.

All Stages run in sequence. Jobs in the same state are executed in parallel. Only when all Stages are successfully executed, the stage succeeds. When one Stage is complete, the next Stage will begin, and the Pipeline will be successful only when all Stages are complete. If any job in the same state fails to be executed, the state fails to be executed. If any Stage fails, subsequent Stages do not execute and the Pipeline fails.

variables

In addition to variables defined by Runner, you can also build variables according to your own needs.

jobs

Every job must have a unique name. It defines the behavior of the job by a set of parameters. Stage: Indicates which stage the job belongs to. Only: defines the job execution condition. In this example, dev-job1 must be the dev branch and the build command must be added to the submission information. Script: command or script executed by runner. In this case, a shell script is executed to package the project build and put the packaged files into the corresponding domain folder to complete the release.

The full keywords of job can be found on the official website

tags

Specific Runners can be selected to perform the job from all Runners allowed to run the project. (Tag set when registering runner in step 2)

Build and release

When the code of the corresponding branch is submitted, add the — Build instruction in the submission information to complete the automatic test build release.