In daily development, how to improve the delivery efficiency, to create an efficient, flexible, highly available CI(continuous integration) /CD(continuous delivery) system, has been an old topic. There are already many open source projects and tools for this, such as Jenkins, Travis, and the GitLab CI discussed in this article.

Introduction to GITLab CI

To get a better idea of what CI/CD does, let’s start with a diagram from GitLab’s official documentation.

From left to right, first comes the submission of the code in GitLab, which triggers the Runner to execute the defined service (including build/ Unit test, etc.).

Then came codeReview, pre-release, officially deployed online.

This is pretty much the same process for every company, and using an automated CI process can greatly speed up development iterations.

GitLab CI terms

  • Job, which is the smallest unit of work and is responsible for only one thing, compilation/testing, etc.

  • Each Job has a Stage. A Stage can contain multiple jobs. There is a sequence of stages. The sequence of Job execution can be controlled indirectly through stage.

  • Pipeline, a sequence of stages is Pipeline;

  • GitLab Runner actually processes jobs. Each Runner can be configured separately. Runner supports multiple types of jobs, and a single Runner can only process one Job at the same time.

  • Executor. Each Runner needs to specify an Executor to determine which Executor the Runner will ultimately use for processing. (The shell used in the following project can also be docker, etc.)

A typical Pipeline has five stages: Build, Test, Release, Staging, and Production. Each stage has at least one Job, and Test has two jobs. GitLab sends tasks to Runner from left to right, and by default, if a single task fails, the Pipeline exits.

Gitlab Runner

Gitlab-runner receives and processes GitLab definition pipeline through HTTP. Runners can be installed on different machines.

More specific gitlab Runner installation and configuration is not discussed in this article, interested can see the corresponding link below to view or Google yourself.

GitLab runner: www.cnblogs.com/cnundefined…

Configuration (. Gitlab – ci. Yml)

Learnxinyminutes.com/docs/yaml/ yml grammar portal

# Define which phases need to be performed, in order by default
# by default, the next phase can be executed after the previous phase is successfully executed
stages:
  - build
  - deploy

# define variables
variables:
  GIT_CLEAN_FLAGS: none

# the build task
build:
  This task belongs to the build phase with the same name. As mentioned above, a phase can have multiple tasks, which will be executed in parallel
  stage: build
  variables:
    NODE_ENV: production
    BOSS_ENV: test
  # The corresponding runner configures the shell, which will be executed as a shell script
  script:
    - yarn --production=false
    - NODE_ENV=$NODE_ENV BOSS_ENV=$BOSS_ENV yarn build
  Execute the intermediate, which will be passed to the next stage
  # will also appear on the GitLab Pipleline page for viewing and downloading
  artifacts:
    expire_in: 1 week
    paths:
      - dist
  # bind runner with tag 'vue' to perform the operation
  tags:
    - vue
  Only if the test branch commits
  only:
    - test

The # deploy phase configuration is roughly the same
Copy the code

See the official configuration document yamL for more details

The development of welfare

Corresponding to the above gitlab-CI configuration, when we develop the test environment, we only need to merge the changes into the test branch, which saves the trouble of raising work orders by ourselves.

The reason why we should combine the test branch with ourselves is that file conflicts are resolved by ourselves. Without the file locking function of boss system, it is inevitable that there will be file conflicts.

Of course, the most important thing is to keep the good habit of closing the master before submission.

After completing the above steps, enjoy gitLab’s beautiful visual pipeline interface. The following map shows an example of a project.

Pipeline list, which can clearly see the passing status and total execution time of each stage

Jobs in individual pipelines are visible, execution results are visible, and artifacts, including artifacts, can be downloaded and viewed online

In a textbook level pipeline, you can see that state jobs can be executed in parallel

The job execution log is also visible

Artifacts that can be viewed online can also be downloaded and viewed online, and need to be configured in the Job

Other Supporting Configurations

  1. Message push integrationIntegrationsOther functions can be extended, selected herePipelines emailsFor notification of execution results

What if you just want to get a reminder about yourself? There is a way, open the notification Settings, select off other reminders can be.

It should be a future

  1. Use enterprise wechat robot to push @designated person’s message in relevant groups to avoid the situation that Foxmail is not opened
  2. use docker image

For the front end, it’s time to try nodeJS

Other options are available

webhook

When webhook listens to the trigger of the corresponding hook, it requests the defined URL, and the corresponding service of the URL completes the subsequent operations. Therefore, it is necessary to write a back-end service separately, which is not well shared between projects.

jenkins

Comparison with GITLab CI: Disadvantages:

  1. The deployment configuration is separated from the code repository, making it difficult for developers to maintain it themselves
  2. Lack of natural support for Docker and K8S

Some others are available for reference: about.gitlab.com/devops-tool… www.thecodecampus.de/blog/jenkin…

My blog is synchronized to tencent cloud + community, invite everyone to come together: cloud.tencent.com/developer/s…