记一次代码事故之后

写在前面：近来管理的事儿做得多了些，也就多了些时间去思考什么是公司的“工程师文化”。所谓文化，一定是整个公司都浸淫着的氛围，得靠点滴小事才能折射出来。所以就开始随手记一些工作中的小事儿，给自己一些答案，放在这里也能和大家多一些交流。

某下午，大家正各自忙活着，忽然传来一声吼：“都别pull代码哈，master上的代码不知被谁revert成两个月前的了！”（没错，就是百姓网网站的代码库）。立刻，锁部署系统（后来验证部署系统还是有足够防范不会把老代码直接发布的，但当时那个紧张呀），手工恢复代码库，几个人折腾了快一个小时，才安定下来开始找元凶：是一个实习生小朋友犯迷糊想pull却打成了push --force，指向主repo的master。

几个人坐下来讨论今后该如何防范类似问题。
取消实习生的master写权限？这会严重影响实习生和他mentor的生产效率，不可取；更何况，正式员工也会犯错呀，是不是他们也要根据资历分出个三六九等呢？
那就做更多的mentoring、教会了才给权限？可这次新人的mentor可是公司里最著名的布道github工作流程的人，真的全都教过、教会了，新人只是一时迷糊而已。

那怎么办？

最终的方案：
1. 取消所有人的baixing repo的写权限，只能在自己的repo上修改。
2. 所有工程师要merge代码时就向一个robot发送merge命令。robot会进行各种校验（merge命令发起方的身份、是否有PR、PR是否有reviewer给出LGTM、接下来还考虑加UT等等），成功后才会用robot的账号执行merge操作。
3. 由于同学们已经习惯了在github上review代码然后点merge按钮了，我们就写了小段油猴脚本，把github PR下面那个merge按钮变成了给robot发merge命令。

于是，除了需要设置一下油猴插件，之前的工作方式几乎没有任何改变，堪称完美！

一场虚惊后，我们的工作方式又进化了一步。我们一直都信奉breaking things and moving fast，有很多地方为了效率我们会采取一些（以我之前在微软时的标准来看）简单粗暴甚至危险的方式。随着公司的成长，我们要学着避免breaking things，但如何在避免它的同时又不影响moving fast，是一个很值得研究的话题。今后应该不断会有case扔出来和大家交流。

5.28携程事故，左耳朵耗子说了段话特别有道理，结合着咱们自己的事情回顾、自夸一下 :P

技术上出故障是必然的。能否体现一个公司是技术公司，重要看这几点：1）故障的恢复是否有技术含量，2）公司对故障的处理方式，如果是通过加更多的流程，或是通过加更多的权限管控，或是通过处罚犯错误的人，或是上升到员工意识形态上，而不是去用更好的技术来解决，那么这个公司不会是个技术公司。

zhuang

2015-08-02 23:57:11 +08:00

以前遇到过类似的事情，现在来看还是个“流程”问题。

Github workflow 强调 master 就是可部署版本。

所以我更倾向于限制 master 的写权限。

在 master 之外建立 test 分支，可以让所有人对 test 可写，此分支的主要用途在于 CI。

只有 CI 每日构建成功的版本才会定期合并到 master，当日构建失败或者发生重大事故可以由 master 恢复，也可以无条件回滚至前一日构建版本上。

还是要坚持 Issue-PR-Merge 流程，去掉前两步看似走得快了，但是步子太大，容易扯着蛋。

我不清楚机器人账号执行写操作的具体实现是什么，但我想到几点由此带来的问题：

需要另一套日志系统记录提交给机器人的指令，或者将相关信息写入 commit log 当中。两套方案各有利弊。

github 更新可能会破坏现有的工作流程。

最后也是最重要的一点：

仍旧不能避免“推送了一个不可部署的版本到 master 分支”的问题。