如果你用 GitLab 来做项目管理，我非常建议你了解一下 GitLab 的 CI/CD 的功能，它可以自动帮你完成项目的打包、部署、上线。

免去了上线过程中的复杂操作，对于标准化流程机器向来比人做的好。也能减少很多不必要的 Human Error 。

本文以 Python 项目部署为例，讲一下 CI/CD 中的一些部署思路，给你一个引子，引出你对 CI/CD 更多的探索。

概括来讲，CI/CD 包含两个关键步骤：配置和执行，只要你的项目根目录里有 .gitlab-ci.yml 配置文件，GitLab 就会读取，然后按照配置去执行计划。

配置： 是通过 GitLab CI 配置文件 (.gitlab-ci.yml )来告诉，执行者（Runner）要做哪些事情
执行：执行的动作是由 Runner 来做的, Runner 是一个可执行程序，可以在任意一台服务器上。项目可以配置一个或多个 Runner。

关于配置

以下是 .gitlab-ci.yml 的一个模板，可以复制到你项目中改改就可以完成你项目的自动部署功能。

stages: # 定义步骤
  - deploy
deploy_test: # job 名称
  image: instrumentisto/rsync-ssh:latest # 指定 docker 镜像
  stage: deploy # 所属的步骤
  script: # 执行的脚本
    - mkdir -p ~/.ssh
    - echo -e "Host *\n\tStrictHostKeyChecking no\n\n" > ~/.ssh/config
    - echo "$TEST_SSH_PRIVATE_KEY" >> ~/.ssh/id_rsa # 将 GitLab 里设置的的私钥环境变量输出到 ～/.ssh/id_rsa
    - chmod 600 ~/.ssh/id_rsa
    - ssh -p 22 -i ~/.ssh/id_rsa root@"$TEST_SERVER" "cd $TEST_PROJECT_PATH && git pull && source .venv/bin/activate && pip install -r requirements.txt && python test.py "
  retry: 2 # 如果任务执行失败，会进行 2 次的重试
  only:
    refs:
      - test # 仅当代码被推送到 test 分支时才会触发该步骤
deploy_prod:
  image: instrumentisto/rsync-ssh:latest # 指定镜像
  stage: deploy
  script:
    - mkdir -p ~/.ssh
    - echo -e "Host *\n\tStrictHostKeyChecking no\n\n" > ~/.ssh/config
    - echo "$PROD_SSH_PRIVATE_KEY" >> ~/.ssh/id_rsa # 将 GitLab 里设置的的私钥环境变量输出到 ～/.ssh/id_rsa
    - chmod 600 ~/.ssh/id_rsa
    - ssh -p 22 -i ~/.ssh/id_rsa root@"$PROD_SERVER" "cd $PROD_PROJECT_PATH && git pull && source .venv/bin/activate && pip install -r requirements.txt && supervisorctl restart server"
  retry: 2
  only:
    refs:
      - master

配置文件包含 stages 和 Job 两个概念。stages 根据项目上线一共有多少个环节来定义，如你可以能有「构建」（build）->「测试」(test)->「部署」(deploy)。我这里为了演示方便只配置了一个 deploy, stage 名称可以随意取，但是尽可能的语义化一些，这样在仓库看日志会比较清晰。

Job 是定义某个 stage 具体做哪些事情。Job 是由 Runner 来执行的。接下来介绍一下 Job 的常用配置。

Script：：可以分为多行，每行都可以执行任意你想执行的 shell 命令。
变量： 变量可以存储一些敏感信息，例如服务器 IP、密码……，变量在 GitLab 项目设置里进行设置。 Script 中可以通过 $+变量名来引用变量。
stage：配置 Job 属于哪个 step。多个 Job 可以共同归属于一个 stage，例如一个 test stage 可以包含单元测试 (Job 1)和静态代码检查 (Job 2)等。
only.refs：用来执行 Job 由哪个分支提交代码来触发执行，一般用来区分环境，比如用 test 分支来触发 Job 部署测试环境。
image：来指定 Job 执行容器的镜像名，不配置就会在 Runner 所在的主机上执行。

配置变量

变量设置

Runner 注册

Runner 注册信息

在注册 Runner 之前，需要先到项目中找到项目的注册信息。

GitLab runner 启动

docker run -d --name gitlab-runner --restart always \
  --env TZ=Asia/Shanghai \
  -v /home/gitlab-runner/config:/etc/gitlab-runner \
  -v /var/run/docker.sock:/var/run/docker.sock \
  gitlab/gitlab-runner:latest

注册 GitLab runner

docker run --rm -t -i gitlab/gitlab-runner register

在对话中输入你自己的仓库信息即可，在上图中可以看到

Runtime platform                                    arch=amd64 os=linux pid=7 revision=5316d4ac version=14.6.0
Running in system-mode.                            
                                                   
Enter the GitLab instance URL (for example, https://gitlab.com/):
你的 gitlab 地址，上图中第二步的地址
Enter the registration token:
这里输入你的 token，上图中第三步的地址
Enter a description for the runner:
[769a8d43d15f]: your description
Enter tags for the runner (comma-separated):

Enter an executor: docker-ssh+machine, custom, docker, parallels, shell, docker+machine, docker-ssh, ssh, virtualbox, kubernetes:
docker
Enter the default Docker image (for example, ruby:2.6):
alpine

这里需要注意一下，如果你的 Runner 服务器和 gitlab 服务器在同一内网，Enter the GitLab instance URL 可以填写内网地址例如： http://192.168.3.33

这么做的好处就是，当 runner 有产物上传的时候，流量是走的内网，速度会更快，也能节省公网带宽。

完成注册后，可以在项目中的 Runners activated for this project 看到你看啊可能注册的 Runner

启动 Runner

总结

到这里基本上就可以完成一个项目的部署了，当然本文介绍的相对比较简单，CI/CD 本身想象空间非常地大。

你可以将项目的打包、静态代码检查，单元测试等等功能都集成进去，保障上线后的稳定。最后也希望本文能完成最初的目标——帮你初步认识 GitLab CI/CD。

扩展阅读

.gitlab-ci.yml 文件：https://gitlab.cn/docs/jh/ci/yaml/gitlab_ci_yaml.html

关于配置#

配置变量#

Runner 注册#

GitLab runner 启动#

注册 GitLab runner#

总结#

扩展阅读#