在倍洽(BearyChat)目前提供的眾多機(jī)器人里， GitHub 機(jī)器人是非常受歡迎的一個(gè)，它使 GitHub Flow 變得更加有效率，在保證質(zhì)量的基礎(chǔ)上提高開發(fā)速度。近日，倍洽又推出了一套基于 Hubot 的輔助插件，進(jìn)一步幫助用戶實(shí)現(xiàn)直接在聊天窗口中完成與 GitHub 更多交互的需求。
場景 1：直接在聊天窗口中向 GitHub 項(xiàng)目添加 Issue
在聊天窗口中與同事交流的各種想法，或者收到的各種用戶反饋，在短暫的溝通后，如果達(dá)成共識，工程師通常會在對應(yīng)的 GitHub 項(xiàng)目上建立一個(gè) Isuue 作為備忘，并逐步添加更具體的細(xì)節(jié)和實(shí)現(xiàn)方案。引入相應(yīng)的 Hubot 插件后，可以直接在聊天窗口中以對話命令的方式實(shí)時(shí)將 Issue 內(nèi)容同步到 GitHub 相應(yīng)位置，這降低了因?yàn)榇翱谇袚Q而造成的記錄遺漏或記錄有誤等情況發(fā)生的概率。
場景 2：檢查自己的 Issue 和 Pull Request
對于那些習(xí)慣于專注工作的工程師，保證每天穩(wěn)定時(shí)間的編程和代碼審查是提高他們工作效率的秘訣。一般而言，在每天的正式工作開始前，他們通常會先查看當(dāng)前自己需要做的工作，并到 Github 上查看所有分配給自己的 Issue。此外，每天也會安排出專門的代碼審查時(shí)間，去檢查分配給自己的 Pull Request。
如果這時(shí)候只需要在聊天窗口中向機(jī)器人發(fā)布相應(yīng)命令即可獲取某個(gè)項(xiàng)目下自己所有需要完成的 Issue 和需要自己審查的 Pull Request，就會大大提升他們進(jìn)入工作狀態(tài)的速度?，F(xiàn)在，借助倍洽和 Hubot 插件可以很輕松的實(shí)現(xiàn)以上場景。
場景 3：發(fā)布 Release Tag
每一個(gè)項(xiàng)目里程碑實(shí)現(xiàn)和每一次代碼上線時(shí)，很多團(tuán)隊(duì)都會為其添加新的 Release Tag，這有助于部署流程的完善，大家可以使用 Tag 來安全的上線代碼，已及回滾代碼。
同時(shí)，每次發(fā)布 Release 的內(nèi)容也是一個(gè)很有用的信息。很會團(tuán)隊(duì)會使用一個(gè)叫 legilimens 的工具，來獲取這次 Release 對比上一次有哪些新的 Pull Request 被合并的信息。
現(xiàn)在，可以借助 Hubot 機(jī)器人自動向聊天窗口中生成一份待驗(yàn)證的功能列表，并且，借助這份列表，也可以在上線后發(fā)現(xiàn)問題時(shí)，幫助大家快速定位問題所在。
這個(gè)聽起來十分順暢的流程是否還有優(yōu)化的空間?答案是肯定的，以上列表生成前，需要人工向 GitHub 的表單填寫許多內(nèi)容，經(jīng)常容易操作錯(cuò)誤。Hubot 機(jī)器人支持使用問答的形式來發(fā)布 Release，就降低了操作的難度，也在一定程度上降低了出錯(cuò)的可能性。
以上功能可以使用開源插件 hubot-githuber 來實(shí)現(xiàn)。在使用時(shí)需要注意的是，必須預(yù)先設(shè)置好 HUBOT_GITHUBER_ACCOUNT 環(huán)境變量(通常是企業(yè)的 organization name)，在機(jī)器人配置完成后，使用者還需要與 Hubot 私聊 github token。
申請創(chuàng)業(yè)報(bào)道，分享創(chuàng)業(yè)好點(diǎn)子。點(diǎn)擊此處，共同探討創(chuàng)業(yè)新機(jī)遇！
