记一次代码事故之后

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

某下午，大家正各自忙活着，忽然传来一声吼：“都别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）公司对故障的处理方式，如果是通过加更多的流程，或是通过加更多的权限管控，或是通过处罚犯错误的人，或是上升到员工意识形态上，而不是去用更好的技术来解决，那么这个公司不会是个技术公司。

realpg

2015-08-03 10:45:24 +08:00

我觉得楼主公司使用github的姿势不正确。

我没用过github的private服务，我还不知道他们的权限管理体系是啥样的。我这边正式项目用git的不多，如果用git，使用的是我曾经的一个git大牛同事自建的一套类似github的系统（PS 经过授权我可以带到别的公司去搭建使用），我们的套路是员工双账号，开发账号fork出来自己的库，只能发pull request，然后由另外一个任何有权做code review的人开浏览器隐身模式登陆有权限账号进行final code review，如果code review通过则merge进申请的分支。

就算你是CTO亲自写的代码，你也得经过别人的final code review才能进主库，任何时候包括线上紧急BUG修复也不允许自己写程序自己merge

自己merge是最大的大坑；任何人都会有一种自我感觉良好。