preface

Three times throughout human history and the development of the industrial revolution, you will find that the use of machines to replace part of the human labor, the repetitive work is the inevitable developing trend of automation to liberate productivity, in the field of software engineering is not exceptional also, which is one of the CI/CD, then what is CI/CD, online explanation not too much, I’ll just show you a flowchart from the Gitlab website:

Preparation conditions

  1. Gitlab runner
  2. .gitlab-ci.yml

Gitlab runner

Gitlab Runner is the entire CI/CD actuator, which is the virtual machine that executes the.gitlab-ci.yml file you wrote. Gitlab Runners fall into two categories:

  1. Specific Runner: Used only for the current project
  2. Shared Runner: All projects can use it

Find your project in Settings >Runners and you can see the following interface:


.gitlab-ci.yml

When you have the runner, you can start to write the.gitlab-ci.yml file. The.gitlab-ci.yml file is a description file for the entire CI/CD process, which tells the runner how to perform specific operations. Before going into the details of the configuration, I want to clarify a few important terms in the entire.gitlab-ci.yml:

  1. Job: Job is the core unit of the entire CI/CD. It defines what tasks should be performed under what conditions, and each job is isolated from each other.
  2. Script: attributes of a job that describe the tasks to be performed by the job.
  3. stages: Define the group of jobs. Different jobs can belong to different stages. There are three stages to choose from: Test build deploy: Stages are executed sequentially, but jobs under stages are executed in parallel. The next stage is executed only when the previous stage is successfully executed. If any job fails in the previous stage, the entire pipeline fails.
  4. The entire process is a pipeline.

Here is a.gitlab-ci.yml file for one of my front-end projects as an example:

image: 10.13 the node:
      
stages:
  - test
  - build
  - deploy
  
cache:
  paths:
    - node_modules/
    
before_script:
  ## set proxy
  - export Http_proxy = http://10.2.3.63:3128/
  - export Https_proxy = http://10.2.3.63:3128/

test:
  stage: test
  tags:
    - sams
  script:
    - npm install --no-optional --registry=https://registry.npm.taobao.org
    - npm run lint
  only:
    - master
    - dev

build:
  stage: build
  tags: 
    - sams
  script:
    - npm run build
  artifacts:
    paths:
      - $SOURCE_DIR
    expire_in: 2 mins
  only:
    - master

deploy:
  stage: deploy
  tags: 
    - sams
  before_script:
    ## set debian mirros
    - echo 'deb http://mirrors.aliyun.com/debian/ stretch main non-free contrib' > /etc/apt/sources.list - echo 'deb-src http://mirrors.aliyun.com/debian/ stretch main non-free contrib' >> /etc/apt/sources.list - echo 'deb http://mirrors.aliyun.com/debian-security stretch/updates main' >> /etc/apt/sources.list - echo 'deb-src http://mirrors.aliyun.com/debian-security stretch/updates main' >> /etc/apt/sources.list - echo 'deb http://mirrors.aliyun.com/debian/ stretch-updates main non-free contrib' >> /etc/apt/sources.list - echo 'deb-src http://mirrors.aliyun.com/debian/ stretch-updates main non-free contrib' >> /etc/apt/sources.list - echo 'deb http://mirrors.aliyun.com/debian/ stretch-backports main non-free contrib' >> /etc/apt/sources.list - echo 'deb-src http://mirrors.aliyun.com/debian/ stretch-backports main non-free contrib' >> /etc/apt/sources.list ## Using SSH keys with GitLab CI/CD ## https://docs.gitlab.com/ee/ci/ssh_keys/README.html - 'which  ssh-agent || ( apt-get update -y && apt-get install openssh-client -y )' - eval $(ssh-agent -s) - echo "$SSH_PRIVATE_KEY" | tr -d '\r' | ssh-add - - mkdir -p ~/.ssh - chmod 700 ~/.ssh - echo "$SSH_KNOWN_HOSTS" > ~/.ssh/known_hosts - chmod 644 ~/.ssh/known_hosts  script:
    - scp -r $SOURCE_DIR $DEPLOY_SERVER_USER@$DEPLOY_SERVER_IP:$TARGET_DIR
  only:
    - master
  environment: test
Copy the code

Global configuration

  • image: The Docker image to use will pull the image from The Docker Hub according to the image name you wrote, because our project is a front-end project, so the image configured here is node, and eventually your script will run in the Node docker environment, This ensures that you have the necessary environment dependencies (node)
  • I define all three stages here, but you can define them according to the actual situation of your project. Once defined, the assembly line will be executed in the order you define.
  • Cache: Defines the files to be cached between jobs. Usually, we cache the project’s installation dependencies so that the next job doesn’t have to reinstall the dependencies
  • Before_script: Defines the scripts that need to be executed before all job scripts are executed. Here I set the agent.

The job of the configuration

  • Stage: defines the stage to which the job belongs
  • Tags: Specifies the runner used by the job
  • Script: indicates the script to be executed by the job
  • Only: a constraint on the job. You can specify when the job is triggered. For example, only the Master and Develop branches execute the deploy job, as well as an except attribute indicating when the job is not executed
  • artifacts: To pass results between stages, it is common to define files packaged in the build phase as artifacts so that they can be used directly in the deploy phase. You may be confused about artifacts and cache. It is recommended to read the official instructions for artifacts
  • Environment: Used to define the environment for job deployment, which needs to be combined with the UI interface of Gitlab project. For example, the name I set here is test. After each successful deployment, there will be an additional deployment item in the test environment, and you can redeploy or even roll back to a certain deployment, as shown in the figure below:

In addition, there is a URL property under Environment that defines the server address to deploy to, so you can click a button on the UI to jump directly to the project. If your Gitlab is below 8.11, this can only be manually configured on the UI (above).

SSH keys Enables login without password

It’s inevitable that you will use SSH when you deploy your project, but SSH requires you to manually enter your user name and password, which makes it impossible to automate deployment. Don’t worry, Gitlab has already helped us figure this out. Read the Using SSH Keys with Gitlab CI/CD article on our website to find a solution, or refer to my example code:

## Using SSH keys with GitLab CI/CD
## https://docs.gitlab.com/ee/ci/ssh_keys/README.html
- 'which ssh-agent || ( apt-get update -y && apt-get install openssh-client -y )'
- eval $(ssh-agent -s)
- echo "$SSH_PRIVATE_KEY" | tr -d '\r' | ssh-add - - mkdir -p ~/.ssh - chmod 700 ~/.ssh - echo "$SSH_KNOWN_HOSTS" > ~/.ssh/known_hosts - chmod 644  ~/.ssh/known_hostsCopy the code

Gitlab first allows you to generate a pair of SSH public and private keys, and then add the private key (now added to the environment variable) to the Ssh-agent every time you execute CI/CD. Add the set $SSH_KNOWN_HOSTS (which contains the host you want to SHH) to the known_hosts file, so that the remote machine can recognize your identity when executing SSH commands and implement the no-password login, essentially the same way you implement no-password login locally.

other

The environment variable

Similar to programming variables, environment variables can store some information to be changed or more private, the environment variables can be configured to call the $+ variable name in the script

Checking the Pipeline Status

On the Gitlab homepage, find the Pipeline TAB and open it to see the operation of all the pipelines

The resources

Docs.gitlab.com/ee/ci/READM…

conclusion

This is the first time I tried to use Gitlab CI/CD, and each task takes about 8 minutes. If you do these tasks manually like before, you will need at least 8 minutes each time. Don’t underestimate these 8 minutes, it is a lot of money over time. But there are no guarantees, and as I said at the beginning, simple and repetitive tasks will inevitably be replaced by machines. This is an inevitable law of history. Whether you use it or not, the tide of technology will continue to push forward, so it’s better to embrace it in advance. In addition, this only introduces the tip of the iceberg of Gitlab CI/CD functionality. Gitlab also provides many excellent features, such as CI/CD in merge Request, so more features are still to be explored. If you are interested, you can find them in the official documentation. If there is anything wrong, please correct it. Thank you for your reading!