基于GitLab和docker的CI/CD系统

An engineer, it is said, is someone who can do for a dime what any fool can do for a dollar.

项目在演进过程中，团队有了一套较为完备的开发pipeline，这篇文章将讲述全栈系统中这个较为远离业务的环节 —— DevOps。

概念浅析

开宗明义，为了让大家更好的理解工作，我们先来一波名次的定义。

CI: Continuous Integration, 持续集成，指的是频繁的将代码集成到主干上，每次集成都通过自动化的构建(包括编译、发布、自动化测试)来验证；

CD: Continuous Deliver, 持续交付，指的是在代码集成，也就是分支代码合并到主干之后，能够被手动的触发，是否发布到生产环境，直接让用户体验最新代码；

CD: Continuous Deployment, 持续部署，和持续交付一样，只不过由手动触发变成自动发布，不再需要人为干扰。

GitLab CI/CD

如果想更了解CI/CD在业务层面的意思，可以阅读我的另一篇文章精益开发，关于持续交付。

链路重点

项目开发经历了这样几个阶段：

每个sprint的交付日都紧张兮兮，不同分支的代码都需要往master上合并，push、merge request、conflict、rebase、test，如此往复，单单集成开发的代码都需要一下午的时间；
为了敢于合并，大胆上线，团队写足了自动化测试，完善了Gitlab的pipeline，随后在交付日就只需要半个小时到两个小时；
随后发现部署新版本不方便，就用dockerfile来打包可运行的镜像，然后在交付日我们只需要点击部署就OK了，上线不过十分钟。

在奇迹般的变化背后，有这样几件事值得注意。

阶段一：紧张交付一下午

团队会尽可能在上午完成feature的开发，一般有三个分支需要合并，每个分支合并前后都需要手动运行测试，由于测试都依赖开发环境数据库而不能并发运行，上线之后需要持续监控半小时，很有可能hotfix改bug。

条件的艰苦，使每一次上线都是团队的大事件，也让我学会了代码部署的每一个小细节，更在之后的日子里让我感受到计算机对效率的提升之巨。

阶段二：轻松部署半小时

手动测试到自动测试

利用Gitlab的pipeline流程，在配置好runner后，就可以很轻松的运行自动化测试了。（在刚开始自动化时，我们选用了gitlab的webhook，webhook会在push和merge事件之后，触发一个钩子到特定的机器上运行测试，然后机器上会出现各种耦合，不建议使用）

完善测试

感受到自动化测试的便利之后，为了让团队对上线有信心，我们编写了大量的测试，方方面面测了个遍，终于不再惧怕重构，敢于上线。

testStage:
    stage: test
    image:
        name: image  # 使用合适的镜像，具备测试运行所需要的环境
    services:
        - name: https://hub.docker.com/_/mongo
          alias: mongo  # 使用官方的mongo镜像当作service，可以隔离集成测试的环境，让测试并发运行而不互相干扰
    script:
        - python -m unittest tests.test_a.TestA
    only:
        - develop  # 个性化设置，仅在develop分支上运行，让集成测试更快更方便

Advantages:

并行的测试大大提高了集成的效率；
每次提交都会运行的测试，杜绝了忘记测试的隐患；
测试覆盖率很高，代码上线很放心；
yml文件中的注释都有一些痛的经历：
- 在runner上准备python的虚拟环境非常困难，下文中将说到镜像的由来；
- 为解决共享耦合的测试环境，我依次选用了mock mongo代码技术，local mongod本地mongo方案，和最终确定的mongo service阶段；
- 测试的数量很大，只运行合适的测试可以有效加快效率；

Disadvantages:

测试急剧增多，测试时间变得夸张的长，导致团队害怕push，害怕触发测试；
测试不稳定，漫长的测试中一点出错，全部测试都必须重跑；

阶段三：持续交付真方便

在“痛苦”的自动化测试半小时之后，我们终于有了可交付的master代码库，然后就是重启服务，也就是重启一下机器，这很简单。但是，如果想要增加一台机器、删除一台机器就比较麻烦了。为了实现灰度发布，蓝绿发布，我紧接着开发了以docker为核心的部署系统。

deliverStage:
    stage: deliver
    script:
        # 把旧的镜像拉下来，如果是第一次运行（会拉不到就报错）就直接true跳过
        - docker pull ${OLD_IMAGE} || true
        # 获得sh文件的执行权限，以便运行镜像是容器有权限执行
        - chmod a+x *.sh
        # 打包可运行镜像
        - docker build --pull --cache-from ${OLD_IMAGE} -t ${NEW_IMAGE} -f Dockerfile .
        # 将镜像推送至远端仓库
        - docker push ${NEW_IMAGE}
    only:
        - master
    tags:
        - docker

# Dockerfile —— 打包可运行服务的dockerfile
# 使用这个缓存镜像作为源镜像
FROM ${my-image-repo-url}/gitlab-ci-cache/my-project:cache

# 用gitlab runner上的最新代码，直接覆盖，这样镜像就得到了最新代码
COPY . $APP_HOME
# 覆盖镜像中的run.sh，镜像将在启动最后运行此文件
COPY run.sh /run.sh

无论是重启还是新增，都只需要new一个新的容器，然后拉取可运行的镜像就可以了。

在学会了docker和gitlab CI/CD的流程之后，我重构了系统中的部分环节。

使用docker缓存python虚拟环境

docker系统的缓存层做的很棒，每执行一条新的语句就会生成一个新的镜像层，如果语句没有变化，则会直接使用已有的缓存层来继续执行下一条语句。

这样的话，如果我的Pipfile和Pipfile.lock（pipenv的依赖管理文件）没有发生变动，就直接使用现有的虚拟环境包文件，可以极大的优化pipeline的流程，极大的缩短pipeline的时长。

# Dockerfile.cache
# 环境缓存层的镜像dockerfile
FROM ${my-image-repo-url}/centos_py3:latest

ENV APP_HOME /home/my-project/

# 这里将最新的Pipfile复制到镜像中
COPY Pipfile $APP_HOME
COPY Pipfile.lock $APP_HOME

# 如果文件Pip依赖没有变更，这里的RUN语句将直接用镜像层，不会重新运行，可以节省大量的时间
RUN cd $APP_HOME && \
    pipenv install -d --skip-lock

提前打包镜像，使用待发布的镜像做测试

有了虚拟环境的缓存镜像，几乎消除了为自动化测试准备环境的时间，这样我就可以把测试分成很多小的runner job，就一举解决了测试运行时间过长、测试不稳定的问题。

cacheStage:
    stage: cache
    script:
        - do cache with centos_py3 image
    tags:
        - docker

buildStage:
    stage: build
    script:
        - do build with cache image
    tags:
        - docker

testStage-1:
    stage: test
    image:
        name: ${BUILD_IMAGE}
    services:
        - name: mongo
          alias: mongo
    script:
        - do test
    tags:
        - docker

testStage-2:
    stage: test
    image:
        name: ${BUILD_IMAGE}
    services:
        - name: mongo
          alias: mongo
    script:
        - do test
    tags:
        - docker

deliverStage:
    stage: deliver
    script:
        - push build image to prod environment
    tags:
        - docker

做个小结

今年写了几篇文章，个人感觉是更偏技术了，但是阅读者了了，甚至投稿审核都难以通过，还是比较令人受挫的。（可能我并非科班出身，无论是技术重点和写作重点，都需要更多的学习。）

这篇文章也只是一个方向的探索、总结和分享，具体要落地，需要有完备的容器化和docker技术，需要深入了解gitlab.yml和dockerfile的语法知识，需要团队的支持和时间的投入，当然结果也是显而易见的，会极大的优化团队开发效率，加快敏捷团队的迭代速度。

最后鼓励一下自己，哪怕看官不多，但是学习和总结的过程已经令人愉悦了，下面几期讲讲数据结构和基础算法的学习吧。

既然这可能是全栈的最后一篇文章，那么我也做个链接吧。

如何转行做一名程序员？ How to build?
全栈的概念。从零开始的异世界python全栈
人生苦短，我选Python。后端演进 —— python生态
不会写前端的后端不是好架构。前端浅析 —— Vue的妙用
持续交付，你值得拥有。运维基础 —— 派普兰实践

欢迎大家关注、点赞，也非常希望读者能说出自己关心的内容，共同进步，共同成长！