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
- Message push integration
Integrations
Other functions can be extended, selected herePipelines emails
For 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
- Use enterprise wechat robot to push @designated person’s message in relevant groups to avoid the situation that Foxmail is not opened
- 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:
- The deployment configuration is separated from the code repository, making it difficult for developers to maintain it themselves
- 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…