Introduction to the

  1. GitLab

    GitLab is an open-source Git project management application based on Ruby development, which provides similar functions to Github. The difference is that GitLab provides a CE community version of GitLab, which users can deploy on their own servers, so that it can be used for project code hosting repositories within the team.

  2. GitLab CI

    GitLab is a continuous integration service provided by GitLab (GitLab CI has been integrated in GitLab since version 8.0). Just create a.gitlab-ci.yml file in your repository root directory and assign a Runner to the project. The build script you wrote in.gitlab-ci.yml will start executing.

  3. GitLab Runner

    GitLab CI is responsible for the execution of various stages of the process in YML files, while GitLab Runner is specifically responsible for executing the script execution of each stage. Generally speaking, GitLab Runner needs to be installed on a separate machine to bind to the GitLab CI through the registration provided by GitLab. Of course, you can also install it with GitLab, but in some cases, when your code build process is very resource-intensive, Git services that will drag GitLab to provide policies to other users.

  4. Continuous integration/deployment environment

    Continuous integration is the process by which application developers submit code frequently, An environment that automatically builds and tests its committed code, and then determines whether the new committed code can be merged into the main branch based on the Test results. Continuous deployment means automatically deploying code to the generation environment after continuous integration

Enable the GitLab CI function

After GitLab 8.0, you can enable GitLab CI in the following two ways

  1. Create a new.gitlab-ci.ymlThe file is in the root directory of your project
  2. Configure a GitLab Runner for your project

To configure a.gitlab-ci.ymlfile

The.gitlab-ci.yml file is the configuration file used to configure gitlab CI for the build process. It uses YAML syntax, so you need to be extra careful to use Spaces instead of Tabs for indentation. Here is a detailed introduction of its rules through the.gitlab-ci.yml file in my own project

stages: - init - check - build - deploy cache: key: ${CI_BUILD_REF_NAME} paths: -node_modules / -dist / # Define a Job called init: stage: init script: -cnpm install #master_check Job: check the key content on the master branch master_check: stage: check script: - echo "Start Check Eros Config ..." -bash check.sh release only: -master #dev_check Job: dev_check: stage: check script: - echo "Start Check Eros Config ..." - bash check.sh debug only: - dev js_build: stage: build script: - eros build master_deploy: stage: deploy script: - bash deploy.sh release only: - master dev_deploy: stage: deploy script: - bash deploy.sh debug only: - devCopy the code

In the example above, we use the stages keyword to define four stages in the continuous build process: init, CHEC, Build, and deploy

Stages in GitLab CI have the following characteristics:

1. All Stages work in order, that is, when one Stage is complete, the next Stage can be started. The Pipeline will only be successful when all Stages are completed. 3. If any of the Stages fails, the Stages that follow do not execute and the build task failsCopy the code

We then use the Caches field to specify the file directory to share for the next job, if not, GitLab Runner deletes the.gitignore file at the start of each job

Next, we define a job called init, which is declared to be init by the stage field, so this job is executed first, and we do some environment initialization in this job.

This is followed by the check phase, which checks for some basic errors in the code (problems such as code specifications that won’t be detected by the compiler), and some configuration file checks, I named them master_check and dev_check, and the only field tells GitLab that CI will trigger this job only when the corresponding branch has push operation.

Then there is the build phase of the code. Unlike the previous extreme, there is no command to distinguish between branches, so you only need to define a job

Finally, only is used to distinguish the two jobs because different branches need to be published to different environments.

Jobs in GitLab CI also have the following characteristics:

Jobs on the same Stage are executed in parallel. 2. The Stage succeeds only when Jobs on the same Stage are executed successfully. If any Job fails, the Stage fails, that is, the build task failsCopy the code

In my build task, I used only a few keywords depending on my business, and many more like before_script, after_script, etc. See the official GitLab documentation for details

Before we finish.gitlab-ci.ymlOnce the process is written, you can put it in the root directory of the project and then push it to our GitLab. At this point, if you open the Piplines TAB on the project home page, you will find a status identifier ofpendingAs shown in the figure below:



At this point, since the build task also found available GitLab Runner to execute its build script, the status of these tasks will be changed after we plug in GitLab Runner for our projectpenddingbecomerunningthe

Install GitLab Runner

Find a suitable machine for installing GitLab Runner, no matter Windows, Mac or Linux, preferably a relatively idle machine that can be opened 24 hours a day. We found the installation file of our platform and the corresponding installation process on the official website of GitLab Runner. Since I plan to install GitLab Runner on an idle iMac, I will demonstrate the installation of GitLab Runner under MacOS:

The installation process for GitLab Runner on macOS and Linux/UNIX is the same, downloading the compiled binary package directly

  1. Download the GitLab Runner for the GitLab version

    • If your GitLab is later than 10.0, the GitLab Runner executable is renamedgitlab-runner
    sudo curl --output /usr/local/bin/gitlab-runner https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-darwin-amd64
sudo chmod +x /usr/local/bin/gitlab-runner
Copy the code
    • The version must be between 9.0 and 10.0
    sudo curl --output /usr/local/bin/gitlab-ci-multi-runner https://gitlab-ci-multi-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-ci-multi-runner-darwin-amd64 sudo chmod  +x /usr/local/bin/gitlab-ci-multi-runnerCopy the code
    • Before 9.0, due to the new API4 interface enabled after 9.0, so if you are GitLab before 9.0, you need to download the following version, otherwise you will not be able to register your GitLab Runner
    sudo curl --output / usr/local/bin/gitlab-ci-multi-runnerhttps://gitlab-ci-multi-runner-downloads.s3.amazonaws.com/v1.11.1/binaries/gitlab-c i-multi-runner-darwin-amd64 sudo chmod +x /usr/local/bin/gitlab-ci-multi-runnerCopy the code

    I don’t know if you have noticed that the download address link above is v1.11.1, this is the corresponding Gitlab Runner, if your Gitlab is before 9.0 version, using Gitlab Runner v1.11.1 version is still not registered, You can try using several lower versions of GitLab Runner, all GitLab Runner releases are available on the
    GitLab Runner Tagsfind

    If you cannot determine the version number of GitLab by logging in to the server, you can directly visit the home page of GitLab, followed by help, as shown below:

  2. Registered GitLab Runner

    Execute the following command,

    sudo gitlab-ci-multi-runner register
Copy the code

    If your terminal cannot find the command, add the /usr/local/bin directory to the environment variable by exporting PATH=/usr/local/bin:$PATH, or you omitted the chmod command.

    After executing the above command, it will ask you to enter the following information:

    • Please enter the gitlab-ci coordinator URL:
    • Please enter the gitlab-ci token for this runner:
    • Please enter the gitlab-ci description for this runner
    • Please enter the gitlab-ci tags for this runner (comma separated):
    • Whether to run untagged builds [true/false]:
    • Please enter the executor:

    Coordinator urls and tokens can be found in the Runner TAB of the project for which you need continuous integration



    Description and tags are customizable. Whether to build a commit without a tag is also up to you. The default is false, and executer selects shell

    After filling out, if Registering Runner… Succeeded indicates that the Runner has been registered, and when you return to the Runners page for your project, you find another Runner in the Active state

    The last step is to launch our newly registered Runner

    sudo  gitlab-ci-multi-runner start
Copy the code

    “> < span style =” box-sizing: border-box; line-height: 22px; word-spacing: inherit! Important; word-spacing: inherit! Important;

Enable mail reminders of build status

If you want to receive Emails about the real-time status of each Build task, you can enable the Build Emails service under the Service TAB in your project.

conclusion

Building a fast and convenient continuous integration and continuous deployment environment is a very important measure for project development. Whether you use the famous Jenkins or GitLab CI introduced in this paper, it can not only help us save a lot of time in debugging and releasing deployment. It also reduces the contingencies in the release process caused by human factors, effectively reducing the risk in project development.

If you want to talk to me, you can follow my subscription number: