记一次代码事故之后

2015-08-02 22:29:21 +08:00
 Elfe

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


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

13585 次点击
所在节点    程序员
82 条回复
feiyuanqiu
2015-08-02 22:37:17 +08:00
你们的开发可以直接向 master push?
我们公司是用gerrit做管理,有两道审核,我提交之后让组长审了才进入develop分支,然后要发布了让主管合并到 master
XiaoxiaoPu
2015-08-02 22:39:15 +08:00
不能禁止在 master 上 forch push 吗?
9hills
2015-08-02 22:39:36 +08:00
我司要求所有提交必须过code review
gDD
2015-08-02 22:50:39 +08:00
@XiaoxiaoPu 看楼主描述他们用的 GitHub,无法开启禁止 force push 选项。
humiaozuzu
2015-08-02 23:03:21 +08:00
@gDD Github Enterprise 的 org admin 里面可以配置
Elfe
2015-08-02 23:06:22 +08:00
@9hills 我们也要求。只不过是靠自觉。这次加的robot会检查PR下面有没有别的reviewer回复LGTM(looks good to me)

@XiaoxiaoPu 嗯,我们用github,并且希望所有工程师都能merge代码到主干,而merge代码和push用的是同样的写权限,所以……

@feiyuanqiu 我们是工程师代码经同伴review过、unit test跑过、自己线下环境测过,就可以自己merge、自己点deploy按钮了。一天deploy几十次的。 :D:D 这叫moving fast,确实会breaking things,但到目前来看收益大于损失。
dalang
2015-08-02 23:06:23 +08:00
为耗子的评论点赞
Elfe
2015-08-02 23:09:36 +08:00
@humiaozuzu org 配置里,只有 read/write/admin 三种权限。如果禁了push,等于禁了merge。
所以这次是禁merge,但通过一个robot加一段脚本来达到原来一样的效果。
mintist
2015-08-02 23:11:07 +08:00
同Gerrit无法直接push master,一定要至少一个人Review通过才可以
tracyone
2015-08-02 23:13:34 +08:00
哈哈,历历在目的感觉....好好玩
ChiangDi
2015-08-02 23:17:33 +08:00
感觉好像把问题搞复杂了,像 github 那样只让 fork 和发 pr 就好了。
clino
2015-08-02 23:20:23 +08:00
gerrit +1
Elfe
2015-08-02 23:20:33 +08:00
@ChiangDi 没错啊,我们正常的流程就是要fork,改代码,然后发pr,merge。正常流程是绝对不会出问题的。但是,既然每个人都有往主repo的master写入的权限,那就有可能脑抽敲出push --force baixing master这样的命令啊。
humiaozuzu
2015-08-02 23:32:44 +08:00
@Elfe 在 org 页面点 admin tools -> admin 就有

maxiujun
2015-08-02 23:48:00 +08:00
应该还是没玩明白
ChiangDi
2015-08-02 23:50:24 +08:00
@Elfe 看看楼上,github 可以直接禁止 push -force
kaneg
2015-08-02 23:52:44 +08:00
我们公司也出现过类似的事,有个人不知道对master做了什么操作,所有文件(近5万个)的历史只有他一人的一次提交了。或许历史还有,但IDEA的git插件里就看不到文件的修改历史了
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 分支”的问题。
kzzhr
2015-08-03 00:06:19 +08:00
对实习生真关心啊,还找人不 :scream:
之前也听L大夸过一次好,这次感觉就是叼
benjiam
2015-08-03 00:07:37 +08:00
没有gerrit 根本没有解决问题,差评。

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/210303

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX