作者：蒋静

前言

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

构建部署之“痛”

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

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

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

发布分析

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

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

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

1. 容器化发布

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

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

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

2. oss发布

oss 发布和容器化发布流程的区别在于不用打包镜像而是将js、css等资源传到了 oss。通过 oss 发布的应用，只需要记住版本和 oss 上面资源路径的对应关系就可以了。

例如在我们这里的实现是：每次发布完成之后会记下有 hash 的 manifest 的地址，点击回滚后会根据发布 id 找到当次的产物，通过 oss 将 manifest 内容替换为有hash 的，从而就切换了访问的资源（html 的 manifest 地址不变，改变的是 manifest 文件的内容）。

3. 小程序

钉钉小程序的回滚就比较简单了，一般在我们点击回滚之后，内部会通过 http 接口调用小程序的 api 传递需要回滚的版本好后即回滚完成。或者你也可以选择手动到开发者后台的历史版本点回滚。
例如： open.dingtalk.com/document/or…

未来展望

有了完善的部署回滚机制，我们的产研团队才能有更好的交付体验。工作中的业务价值在我们整个交付内容占比应当是比较高的，而不应当把大量的时间花费在处理部署等流程上，让我们能够更快的去完成业务交付。

更好更稳定的回滚方式，能够让我们做到出现问题时快速恢复。这样才能保证一个较低的试错成本。

对于古茗来说，我认为一个很大的优势是，我们的规模不算很大，可以更好地做好研发流程对应的工具服务的统一，打通研发流程的各个流程，每个环节之间更好地进行串联，更好的助力业务发展。