域名預(yù)訂/競(jìng)價(jià)，好“米”不錯(cuò)過(guò)

在倍洽(BearyChat)目前提供的眾多機(jī)器人里， GitHub 機(jī)器人是非常受歡迎的一個(gè)，它使 GitHub Flow 變得更加有效率，在保證質(zhì)量的基礎(chǔ)上提高開(kāi)發(fā)速度。近日，倍洽又推出了一套基于 Hubot 的輔助插件，進(jìn)一步幫助用戶實(shí)現(xiàn)直接在聊天窗口中完成與 GitHub 更多交互的需求。

場(chǎng)景 1：直接在聊天窗口中向 GitHub 項(xiàng)目添加 Issue

在聊天窗口中與同事交流的各種想法，或者收到的各種用戶反饋，在短暫的溝通后，如果達(dá)成共識(shí)，工程師通常會(huì)在對(duì)應(yīng)的 GitHub 項(xiàng)目上建立一個(gè) Isuue 作為備忘，并逐步添加更具體的細(xì)節(jié)和實(shí)現(xiàn)方案。引入相應(yīng)的 Hubot 插件后，可以直接在聊天窗口中以對(duì)話命令的方式實(shí)時(shí)將 Issue 內(nèi)容同步到 GitHub 相應(yīng)位置，這降低了因?yàn)榇翱谇袚Q而造成的記錄遺漏或記錄有誤等情況發(fā)生的概率。

場(chǎng)景 2：檢查自己的 Issue 和 Pull Request

對(duì)于那些習(xí)慣于專(zhuān)注工作的工程師，保證每天穩(wěn)定時(shí)間的編程和代碼審查是提高他們工作效率的秘訣。一般而言，在每天的正式工作開(kāi)始前，他們通常會(huì)先查看當(dāng)前自己需要做的工作，并到 Github 上查看所有分配給自己的 Issue。此外，每天也會(huì)安排出專(zhuān)門(mén)的代碼審查時(shí)間，去檢查分配給自己的 Pull Request。

如果這時(shí)候只需要在聊天窗口中向機(jī)器人發(fā)布相應(yīng)命令即可獲取某個(gè)項(xiàng)目下自己所有需要完成的 Issue 和需要自己審查的 Pull Request，就會(huì)大大提升他們進(jìn)入工作狀態(tài)的速度。現(xiàn)在，借助倍洽和 Hubot 插件可以很輕松的實(shí)現(xiàn)以上場(chǎng)景。

場(chǎng)景 3：發(fā)布 Release Tag

每一個(gè)項(xiàng)目里程碑實(shí)現(xiàn)和每一次代碼上線時(shí)，很多團(tuán)隊(duì)都會(huì)為其添加新的 Release Tag，這有助于部署流程的完善，大家可以使用 Tag 來(lái)安全的上線代碼，已及回滾代碼。

同時(shí)，每次發(fā)布 Release 的內(nèi)容也是一個(gè)很有用的信息。很會(huì)團(tuán)隊(duì)會(huì)使用一個(gè)叫 legilimens 的工具，來(lái)獲取這次 Release 對(duì)比上一次有哪些新的 Pull Request 被合并的信息。

現(xiàn)在，可以借助 Hubot 機(jī)器人自動(dòng)向聊天窗口中生成一份待驗(yàn)證的功能列表，并且，借助這份列表，也可以在上線后發(fā)現(xiàn)問(wèn)題時(shí)，幫助大家快速定位問(wèn)題所在。

這個(gè)聽(tīng)起來(lái)十分順暢的流程是否還有優(yōu)化的空間?答案是肯定的，以上列表生成前，需要人工向 GitHub 的表單填寫(xiě)許多內(nèi)容，經(jīng)常容易操作錯(cuò)誤。Hubot 機(jī)器人支持使用問(wèn)答的形式來(lái)發(fā)布 Release，就降低了操作的難度，也在一定程度上降低了出錯(cuò)的可能性。

以上功能可以使用開(kāi)源插件 hubot-githuber 來(lái)實(shí)現(xiàn)。在使用時(shí)需要注意的是，必須預(yù)先設(shè)置好 HUBOT_GITHUBER_ACCOUNT 環(huán)境變量(通常是企業(yè)的 organization name)，在機(jī)器人配置完成后，使用者還需要與 Hubot 私聊 github token。

申請(qǐng)創(chuàng)業(yè)報(bào)道，分享創(chuàng)業(yè)好點(diǎn)子。點(diǎn)擊此處，共同探討創(chuàng)業(yè)新機(jī)遇！