GitHub 2011–2020：Hubot 將聊天室變成部署主控台

到了 2011 年，GitHub 的小型團隊在 Campfire 聊天室中管理基礎設施，而他們的機器人已變得「越來越龐大、越來越混亂」。他們從頭改寫，並將其開源為 Hubot——一個負責部署程式碼、作為 CI 伺服器前端，並讓維運指令對全公司可見的機器人。

把工具放進聊天室：一個能部署程式碼、執行 CI，並在錯誤激增時通知最後一位部署者的機器人——每個動作都可見、可稽核，且對所有人開放。

Hubot 會監聽像「/deploy my-feature」這樣的指令；工程師從聊天室進行部署，而當異常率激增時，機器人會通知最後一位部署者，並附上內部 Haystack 儀表板的連結，藉此隱含地指派責任。它於 2011 年開源，到了 2020 年，GitHub 仍每週透過 ChatOps 執行 120–150 次生產部署，並採用金絲雀發布，每次部署會批次合併數百個拉取請求。

GitHub 的部署變成任何人都能執行、所有人都能看見的聊天指令：同樣的每週部署次數如今能發布遠多於以往的變更，回滾率維持在足夠低的程度，因而建立起「信任文化」，而「ChatOps」一詞也隨著各團隊仿效這個模式而在業界廣為流傳。

2011 年時，GitHub 是一間規模不大、卻營運著極大型服務的公司，團隊成員整天待在 Campfire 聊天室裡。他們的機器人已變得「越來越龐大、越來越混亂」，於是他們從頭改寫並開源：Hubot，「一個很棒的 Campfire 機器人」，它逗他們發笑、負責部署他們的程式碼，並作為他們 CI 伺服器的介面。

這套做法後來發展成 GitHub 所稱的 ChatOps：工程師在聊天室中執行「/deploy my-feature」，由 Hubot 處理身分驗證、階段與金絲雀發布。當部署後異常激增時，Hubot 會通知最後一位部署者，並附上 Haystack（GitHub 內部的異常儀表板）的連結——「這個通知的直接好處，在於它隱含地指定了負責人」。

到了 2020 年，這個模式已臻成熟：GitHub 的部署團隊描述部署是由「一連串 Hubot 指令」所啟動，每週為 github.com 執行 120–150 次生產部署，單週發布超過 400 個拉取請求，且對流程的信任度足夠高，回滾率維持在低檔，開發者可以合併後就繼續前進。

它移除了「誰有權動生產環境」這個瓶頸——任何工程師都能從聊天室部署，且動作對全公司可見。

機器人讓責任變得隱含：錯誤激增時會通知最後一位部署者，於是問題會找到負責人，而不是枯等分診。

由於每道指令都在共用頻道中執行，部署變得可稽核、可教學——新進工程師透過觀察聊天室來學習維運。

將 Hubot 開源，把一項內部便利工具變成業界模式，並讓「ChatOps」一詞廣為流行。

當內部工具能降低採取行動的社會成本時，它就會勝出：把維運放進聊天室，讓部署變得可見、可稽核，也敢於授權——真正改變文化的，是介面的改變。

ChatOps 成為廣被仿效的做法，Hubot 也發展成社群專案，並有適用於 Slack、Discord 與 Teams 的轉接器。在 GitHub，部署流程持續演進——後來的 IssueOps 與 GitHub Actions 都建立在相同構想之上——而其根本原則，也就是讓人們用他們早已共用的工具來操作基礎設施，始終是 GitHub 出貨方式的核心。