如何安全的实现代码发布

很多互联网公司每一次代码发布像是如临大敌。熬夜，值班，凌晨上线。每次上线都弄得疲惫不堪。其实代码发布并不是将代码发布到线上这一个操作，而是需要一系列的系统和规范构成的。由于各个系统是分开独立的，所以我们通过一个实习生小明作为背景编的故事，通过小明代码发布的过程，来了解一个互联网公司正常安全的实现代码发布。(纯属虚构，如有雷同，实属巧合)

小明是刚来的实习生，所以他的前辈老王分配给他的是一些小功能，修修小bug，熟悉熟悉一下代码和流程。

了解需求

打了两天酱油党的小明今天终于接到一个任务，是对于现有的系统需要新加一些功能。于是开早会的时候小明就被老王带上一起去参加讨论会。

TL/PM上来先交代了下需求的背景，然后提出了一个解决问题的思路。大家纷纷从开发成本，可执行性等方面对这个方案进行评估和完善。由于开会前大家通过会议邮件已经对会议内容有了大致的了解,所以小明也提出了自己的思路。所以这个讨论会的作用更多的像是在投票，决定方案而不是制定方案。这个需求比较简单，会上讨论完后就直接可以进入下一环节了。有的需求复杂或者牵扯比较多的可能还得再开个专门的需求评审。

写文档

在动手之前，小明先把自己的想法和实现方案先在公司的wiki上大致上描述了一遍。因为公司每天的会议很多，而且要做的事也很多，所以过会儿小明就把会上很多细节的事儿都忘了，这时开会上记的笔记帮了他大忙。于是小明很快把文档写完了。把链接发给TL看后，如果没问题就开始写代码了。

写代码

由于之前在公司的git上看过了项目的代码，所以知道公司的代码风格是统一沿用Google style。功能上的逻辑，已经在写文档的时候想好了，技术上的问题，已经在前期调研过了，所以键盘噼里啪啦敲得飞起，代码一下子就写完了。推到git上后，点下按键，发起一个pr, 接着出去休息一下，等待同事的code review。

code review

code review 是需要两个人approve才能够合并到master里面。小明提交pr的时候，他一个项目组的同事小马就已经收到了邮件。因为小马和小明是负责同一块业务，所以小马从代码可读性，逻辑正确，代码优化等角度提出了一些意见。经过来回的几次修改，代码终于可以merge了。

代码集成

主要是解决各种merge冲突。因为是主干开发，所有人都在往trunk上提交代码，所以一般代码是分开功能，分多次提交比较好，不然太久没merge可能代码变化太大改动起来就很麻烦了。

上线

其实这是最关键的一部，也是最不关键的一步。因为有了前面的保障，已经可以排除大部分问题。然后就是上线校验的过程了，毕竟实践才是检验真理的唯一标准。

• 构建
  每一次代码的提交都会触发发布系统的一次程序构建。构建过程即发布系统从代码库抽取最新代码编译打包的过程。如果项目参与的人多的话，发布系统可能每天都会有好几次的构建，发布系统每次构建的都是最新的代码，会有版本号标示，接下来要上线的邮件只需要提交说发布那个版本的版本号就可以了，发布系统会自动发布该版本到线上。
• 功能测试
  测试团队的同学会在这时候编写测试的case，或者根据需求做一些功能性的测试。这要求测试同学对业务非常了解，所以现在团队的测试人员都是跟业务走，而专门的测试部门会越来越少。
• A/BTEST
  通过a/btest系统，先小流量上线，在后台的报表平台实时查看小流量后的各种关键指标。如果有问题则修改bug，重新提交。如果没有问题，则可以逐步全量。这个过程的观测时间根据不同任务而不同。
• 滚动发布
  为了避免全量上线出现系统无法提供服务的情况，代码会逐步滚动发布到线上机器。正常应该不会出现问题。如果出现问题，则执行回滚操作。不过如果有按照前面的步骤执行，几乎很少会出现回滚的情况。所以很多时候上线也可以在白天的流量低的时期进行上线，而无需熬夜上线。为运维和开发同学的身体健康提供了重要的保障。

整个过程有点偏简化，有很多细节也没有提及，例如发布系统应该怎么做，和代码库怎么保持同步，怎么做才能做到一键回滚。code review 时候应该注意哪些。你实现的想法跟代码提交者的想法有冲突怎么办？ 诸如此类，每个环节都可以单独拎出来细说。不过本文重在科普，篇幅所限，所以不详细展开。代码发布不是一次事件，而是一系列的事件构成，从在写代码之前就已经开始了。软件工程发展数十年，可是《人月神话》中提过的坑还是有无数人不断的在踩。希望本文能帮助你在互联网时代，脱离了手工作坊版的简陋形式。当然，如果你所在的公司已经这么执行了，那么恭喜你，你已经初步迈入软件工程的大门了。