作者：蒋静
前言
回滚是每个开发者必须熟悉的操作，它的重要性不言而喻，必要的时候我们可以通过回滚减少错误的代码对用户影响的时间。回滚的方式有很多种，方式有好也有坏，比如说使用 git 仓库回滚有可能会覆盖其他业务的代码，不稳定，构建产物的回滚最安全，便于优先解决线上问题。
构建部署之"痛"
我的几段公司的工作经历：
- 第一段经历，是在一个传统的公司，没有运维，要我们自己登录一个跳板机，把文件部署到服务器，非常麻烦。
- 第二段经历，是在一个初创公司，基建几乎没有，前端的规模也很小，发布就是打个 zip 包发给运维，运维去上线。但是久而久之，运维也就不耐烦了。
- 后来去了稍微大些的公司，构建、部署有一套比较完善的体系，在网页上点击按钮就可以了。
那么构建部署是如何实现的呢？下面我要来介绍古茗的部署和回滚代码机制。
发布分析
我们的最终目的是发布上线，我们发布的是什么呢？是一条分支，所以我们需要先创建一条分支（更加规范的步骤应该是：基于某个需求和某个应用去拉一条分支）。在分支上开发完我们就可以进行发布的操作啦！
这个时候我们就可以操作发布，我们填写需要的配置项后就可以点击发布按钮了。但是肯定不能让所有人随随便便就发布成功，所以我们要进行一些前置校验。比如说你有没有发布的权限、代码有没有冲突、是不是节假日或非发布窗口期、这个应用有没有正在被发布。。。等等的校验，总之就是确保代码是可以被你发布的。
然后我们的发布平台就会叫 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...
未来展望
有了完善的部署回滚机制，我们的产研团队才能有更好的交付体验。工作中的业务价值在我们整个交付内容占比应当是比较高的，而不应当把大量的时间花费在处理部署等流程上，让我们能够更快的去完成业务交付。
更好更稳定的回滚方式，能够让我们做到出现问题时快速恢复。这样才能保证一个较低的试错成本。
对于古茗来说，我认为一个很大的优势是，我们的规模不算很大，可以更好地做好研发流程对应的工具服务的统一，打通研发流程的各个流程，每个环节之间更好地进行串联，更好的助力业务发展。
最后
📚 小茗文章推荐：
关注公众号「Goodme前端团队」，获取更多干货实践，欢迎交流分享~