寫在前面：近來管理的事兒做得多了些，也就多了些時(shí)間去思考什么是公司的“工程師文化”。所謂文化，一定是整個(gè)公司都浸淫著的氛圍，得靠點(diǎn)滴小事才能折射出來。所以就開始隨手記一些工作中的小事兒，給自己一些答案，也和大家多一些交流。
某下午，大家正各自忙活著，忽然傳來一聲吼：“都別pull代碼哈，master上的代碼不知被誰revert成兩個(gè)月前的了！”（沒錯(cuò)，就是百姓網(wǎng)網(wǎng)站的代碼庫）。立刻，鎖部署系統(tǒng)（后來驗(yàn)證部署系統(tǒng)還是有足夠防范不會(huì)把老代碼直接發(fā)布的，但當(dāng)時(shí)那個(gè)緊張呀），手工恢復(fù)代碼庫，幾個(gè)人折騰了快一個(gè)小時(shí)，才安定下來開始找元兇：是一個(gè)實(shí)習(xí)生小朋友犯迷糊想pull卻打成了push --force，指向主repo的master。
幾個(gè)人坐下來討論今后該如何防范類似問題。
取消實(shí)習(xí)生的master寫權(quán)限？這會(huì)嚴(yán)重影響實(shí)習(xí)生和他mentor的生產(chǎn)效率，不可??；更何況，正式員工也會(huì)犯錯(cuò)呀，是不是他們也要根據(jù)資歷分出個(gè)三六九等呢？
那就做更多的mentoring、教會(huì)了才給權(quán)限？可這次新人的mentor可是公司里最著名的布道github工作流程的人，真的全都教過、教會(huì)了，新人只是一時(shí)迷糊而已。
那怎么辦？
最終的方案：
- 取消所有人的baixing repo的寫權(quán)限，只能在自己的repo上修改。
- 所有工程師要merge代碼時(shí)就向一個(gè)robot發(fā)送merge命令。robot會(huì)進(jìn)行各種校驗(yàn)（merge命令發(fā)起方的身份、是否有PR、PR是否有reviewer給出LGTM、接下來還考慮加UT等等），成功后才會(huì)用robot的賬號(hào)執(zhí)行merge操作。
- 由于同學(xué)們已經(jīng)習(xí)慣了在github上review代碼然后點(diǎn)merge按鈕了，我們就寫了一小段油猴腳本，把github PR下面那個(gè)merge按鈕變成了給robot發(fā)merge命令。
于是，除了需要設(shè)置一下油猴插件，之前的工作方式幾乎沒有任何改變，堪稱完美！
一場(chǎng)虛驚后，我們的工作方式又進(jìn)化了一步。我們一直都信奉breaking things and moving fast，有很多地方為了效率我們會(huì)采取一些（以我之前在微軟時(shí)的標(biāo)準(zhǔn)來看）簡(jiǎn)單粗暴甚至危險(xiǎn)的方式。隨著公司的成長(zhǎng)，我們要學(xué)著避免breaking things，但如何在避免它的同時(shí)又不影響moving fast，是一個(gè)很值得研究的話題。今后應(yīng)該不斷會(huì)有case扔出來和大家交流。
5.28攜程事故，左耳朵耗子說了段話特別有道理，結(jié)合著咱們自己的事情回顧、自夸一下 :P
技術(shù)上出故障是必然的。能否體現(xiàn)一個(gè)公司是技術(shù)公司，重要看這幾點(diǎn)：1）故障的恢復(fù)是否有技術(shù)含量，2）公司對(duì)故障的處理方式，如果是通過加更多的流程，或是通過加更多的權(quán)限管控，或是通過處罰犯錯(cuò)誤的人，或是上升到員工意識(shí)形態(tài)上，而不是去用更好的技術(shù)來解決，那么這個(gè)公司不會(huì)是個(gè)技術(shù)公司。
文章末尾必須的廣告：我們?cè)谡衅福?a target="_blank" rel="nofollow">職位看這里。
