写在前面:近来管理的事儿做得多了些,也就多了些时间去思考什么是公司的“工程师文化”。所谓文化,一定是整个公司都浸淫着的氛围,得靠点滴小事才能折射出来。所以就开始随手记一些工作中的小事儿,给自己一些答案,放在这里也能和大家多一些交流。
某下午,大家正各自忙活着,忽然传来一声吼:“都别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)公司对故障的处理方式,如果是通过加更多的流程,或是通过加更多的权限管控,或是通过处罚犯错误的人,或是上升到员工意识形态上,而不是去用更好的技术来解决,那么这个公司不会是个技术公司。
这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。
V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。
V2EX is a community of developers, designers and creative people.