前言

回滚是每个开发者必须熟悉的操作，它的重要性不言而喻，必要的时候我们可以通过回滚减少错误的代码对用户影响的时间。回滚的方式有很多种，方式有好也有坏，比如说使用 git 仓库回滚有可能会覆盖其他业务的代码，不稳定，构建产物的回滚最安全，便于优先解决线上问题。

构建部署之“痛”

我的几段公司的工作经历：

1. 第一段经历，是在一个传统的公司，没有运维，要我们自己登录一个跳板机，把文件部署到服务器，非常麻烦。
2. 第二段经历，是在一个初创公司，基建几乎没有，前端的规模也很小，发布就是打个 zip 包发给运维，运维去上线。但是久而久之，运维也就不耐烦了。
3. 后来去了稍微大些的公司，构建、部署有一套比较完善的体系，在网页上点击按钮就可以了。

那么构建部署是如何实现的呢？下面我要来介绍古茗的部署和回滚代码机制。

发布分析

我们的最终目的是发布上线，我们发布的是什么呢？是一条分支，所以我们需要先创建一条分支（更加规范的步骤应该是：基于某个需求和某个应用去拉一条分支）。在分支上开发完我们就可以进行发布的操作啦！

这个时候我们就可以操作发布，我们填写需要的配置项后就可以点击发布按钮了。但是肯定不能让所有人随随便便就发布成功，所以我们要进行一些前置校验。比如说你有没有发布的权限、代码有没有冲突、是不是节假日或非发布窗口期、这个应用有没有正在被发布。。。等等的校验，总之就是确保代码是可以被你发布的。

然后我们的发布平台就会叫 Jenkins 拿着仓库信息、分支信息，以及其他等等的配置信息去仓库拉取代码了，拉到代码之后根据不同类型的应用进行区分，进行编译打包（这个过程不同应用之间是不同的），生成对应的产物。

1. 容器化

1.1 容器化发布

1.2 容器化回滚

注：图中Wukong是我们自研DevOps平台

容器化发布发布的是镜像，镜像 id 代表了这次发布和这个镜像的关联关系。回滚的时候只需要找到这次发布对应的 id ，运维脚本根据这个 docker 的 id 找到 docker 镜像，直接部署这次 docker 镜像，做到回滚。由于发布的是 docker 的镜像，不仅可以保证产物是相同的，发布还很快。

容器化之前的发布：先找到对应的发布，根据这次发布找到对应的 tag，然后打包发布，但是这样只能保证业务代码是相同的，不能保证机器环境、打包机的环境、依赖的版本、打包的产物等等是一样的，并且需要的时间比容器化的方式慢得多。