我想在gitlab用CI/CD部署

May 13, 2021 · 3 min read · gitlab git CI/CD ·

分享到:

持续集成

持续整合（英语：Continuous integration，缩写CI），又译为持续集成，是一种软件工程流程，是将所有软件工程师对于软件的工作副本持续集成到共享主线（mainline）的一种举措。该名称最早由[1]葛来迪·布区（Grady Booch）在他的布区方法[2]中提出，在测试驱动开发（TDD）的作法中，通常还会搭配自动单元测试。持续集成的提出主要是为解决软件进行系统集成时面临的各项问题，极限编程称这些问题为集成地狱（integration hell）。

持续交付

持续交付（英语：Continuous delivery，缩写为 CD），是一种软件工程手法，让软件产品的产出过程在一个短周期内完成，以保证软件可以稳定、持续的保持在随时可以释出的状况。它的目标在于让软件的建置、测试与释出变得更快以及更频繁。这种方式可以减少软件开发的成本与时间，减少风险。

持续部署

持续部署（英语：Continuous deployment，缩写为CD），是一种软件工程方法，意指在软件开发流程中，以自动化方式，频繁而且持续性的，将软件部署到生产环境（production environment）中，使软件产品能够快速的发展[1][2][3]。

持续部署可以整合到持续整合与持续交付（Continuous delivery）的流程之中。

CI/CD

在软件工程中，CI/CD或CICD通常指的是持续集成和持续交付或持续部署的组合实践。CI/CD通过在应用程序的构建、测试和部署中实施自动化，在开发和运营团队之间架起了桥梁。

现代DevOps实践涉及软件应用程序在整个开发生命周期内的持续开发、持续测试、持续集成、持续部署和持续监控。CI/CD实践或CI/CD管道（CI/CD pipeline）构成了现代DevOps业务的主干。

缘由

公司运维系统每次发布系统都需要经过一轮打包——编译——发至跳板机（期间需要输入动态码）——然后登陆跳板机（需要输入动态码））——从跳板机将压缩包发至web主机——再登陆web主机再解压缩新包并重启。一轮下来，费时费力不说，命令行忘记，手打输入错误等情况，还是会经常出现的。可能大家会觉得这么简单的事还说难，但是，事情有时候不是说只做这一件，事情也不是天天都做，还有就是，同事的加入或离开，都需要重新弄这一套流程。跳板机需要配置申请，各方面需要重新指导，其实很费时间。

本次的接入，也是由控制台那块流程已经接入至cicd，所以也就是有前车了，不怕，有问题问大佬，这么说都写了一套了。

过程

目前只做一个管道（pipeline）操作，里面主要实现的工作就是上面我们手动要做的那些事。我们把整个空间就是个docker空间所以第一件事就是，先安装依赖再进行编译。没啥问题！

.gitlab-ci.yml

 1image: node:13.11.0
 2
 3stages:
 4  - build
 5
 6# 构建
 7deploy:
 8  stage: build
 9  script:
10    - echo '---------- build ------------'
11    - npm install
12    - npm run build
13  tags:
14    - 此处填入自己的tags

编译完之后就是打包发至服务器了，此处直接去跳板机处生成自己的ssh private key并保存只仓库中的CI/CD的变量SSH_PRIVATE_KEY_133当中，并将web主机加入known_hosts里面。

 1before_script:
 2    #- apt-get -y install openssh-client
 3    - 'which ssh-agent || ( apt-get update -y && apt-get install openssh-client -y )'
 4    - eval $(ssh-agent -s)
 5    - echo "$SSH_PRIVATE_KEY_133" | tr -d '\r' | ssh-add - > /dev/null
 6    - mkdir -p ~/.ssh
 7    - chmod 700 ~/.ssh
 8    - echo "$SSH_KNOWN_HOSTS" > ~/.ssh/known_hosts
 9    - '[[ -f /.dockerenv ]] && echo -e "Host *\n\tStrictHostKeyChecking no\n\n" > ~/.ssh/config'
10    - chmod 644 ~/.ssh/known_hosts
11

将key加入至此后，尝试发至web主机。

1
2    - TZ='Asia/Shanghai'; export TZ; export VERSION=`date +%Y%m%d%H%M%S`
3    - export Y_VERSION=`date +%Y`
4    - echo $VERSION
5    - tar zcvf dist-$VERSION.tar.gz dist
6    - scp dist-$VERSION.tar.gz $DEPLOY_USER@$DEPLOY_HOST:$DEPLOY_PATH-pre/tars/$Y_VERSION

如图可见，是发送成功了

那现在就简单了，ssh登陆。

1- ssh $DEPLOY_USER@$DEPLOY_HOST "cd '$DEPLOY_PATH'-pre && tar -zxvf tars/'$Y_VERSION'/dist-'$VERSION'.tar.gz && pm2 restart 14"

后续

目前这个已经可运行并且开始使用。效果大概是5分钟左右可以发布完所有流程，本来是希望通过引入cache机制去跳过npm install的步骤，但目前公司提供的机器无法提供cache缓存。而且加入cache配置后，管道运行时间竟然超过12分钟。。。

下个版本

这个只是一个管道，没有全部分离出来。以后可以进行分解加强。 1）加eslint校验 2）css校验 3）编译独立 4）发布流程独立并且正式环境需手动发布

目前主要源码：

 1# This file is a template, and might need editing before it works on your project.
 2# Official framework image. Look for the different tagged releases at:
 3# https://hub.docker.com/r/library/node/tags/
 4image: node:13.11.0
 5
 6before_script:
 7    #- apt-get -y install openssh-client
 8    - 'which ssh-agent || ( apt-get update -y && apt-get install openssh-client -y )'
 9    - eval $(ssh-agent -s)
10    - echo "$SSH_PRIVATE_KEY_133" | tr -d '\r' | ssh-add - > /dev/null
11    - mkdir -p ~/.ssh
12    - chmod 700 ~/.ssh
13    - echo "$SSH_KNOWN_HOSTS" > ~/.ssh/known_hosts
14    - '[[ -f /.dockerenv ]] && echo -e "Host *\n\tStrictHostKeyChecking no\n\n" > ~/.ssh/config'
15    - chmod 644 ~/.ssh/known_hosts
16  
17stages:
18  - build
19
20# 构建
21pre-auto-deploy:
22  stage: build
23  only:
24    refs:
25      - pre-release
26      - feature/test_CI
27  script:
28    - cd $CI_PROJECT_DIR && pwd
29    - >
30      if [ ! -d "./node_modules" ] || [ ! "$(ls -A './node_modules')" ]; then
31        echo '---------- install ------------'
32        npm install
33          if [ $? -ne 0 ]; then
34            echo "npm_install error"
35            exit 1
36          fi
37      fi
38      
39    - echo '---------- build ------------'
40    - npm run build
41    - TZ='Asia/Shanghai'; export TZ; export VERSION=`date +%Y%m%d%H%M%S`
42    - export Y_VERSION=`date +%Y`
43    - echo $VERSION
44    - tar zcvf dist-$VERSION.tar.gz dist
45    - scp dist-$VERSION.tar.gz $DEPLOY_USER@$DEPLOY_HOST:$DEPLOY_PATH-pre/tars/$Y_VERSION
46    - ssh $DEPLOY_USER@$DEPLOY_HOST "cd '$DEPLOY_PATH'-pre && tar -zxvf tars/'$Y_VERSION'/dist-'$VERSION'.tar.gz && pm2 restart 14"
47  #cache:
48  #  key: ${CI_COMMIT_REF_SLUG}
49  #  paths:
50  #    - node_modules/
51  tags:
52    - 一个tags
53    
54prod-auto-deploy:
55  stage: build
56  only:
57    refs:
58      - develop
59      - feature/test_CI_D
60  script:
61    - cd $CI_PROJECT_DIR && pwd
62    - >
63      if [ ! -d "./node_modules" ] || [ ! "$(ls -A './node_modules')" ]; then
64        echo '---------- install ------------'
65        npm install
66          if [ $? -ne 0 ]; then
67            echo "npm_install error"
68            exit 1
69          fi
70      fi
71      
72    - echo '---------- build ------------'
73    - npm run build
74    - TZ='Asia/Shanghai'; export TZ; export VERSION=`date +%Y%m%d%H%M%S`
75    - export Y_VERSION=`date +%Y`
76    - echo $VERSION
77    - tar zcvf dist-$VERSION.tar.gz dist
78    - scp dist-$VERSION.tar.gz $DEPLOY_USER@$DEPLOY_HOST:$DEPLOY_PATH/tars/$Y_VERSION
79    - ssh $DEPLOY_USER@$DEPLOY_HOST "cd '$DEPLOY_PATH' && tar -zxvf tars/'$Y_VERSION'/dist-'$VERSION'.tar.gz && pm2 restart 8"
80  #cache:
81  #  key:
82  #    files:
83  #      - package-lock.json
84  #      - package.json
85  #    prefix: $CI_PROJECT_NAME-$CI_JOB_NAME
86  #  paths:
87  #    - node_modules/
88  tags:
89    - 一个tags

CI的编写可以再gitlab页面上进行CI lint检查

REF

https://docs.gitlab.com/ee/ci/
https://twblog.hongjianching.com/2020/05/09/GitLab-CI-CD-use-cache-and-artifacts/
https://www.jianshu.com/p/b835a4d5bb4e
https://docs.gitlab.com/ee/ci/caching/
https://docs.gitlab.com/ee/ci/variables/README.html