GitHub自動化多階段部署程序，解決貢獻者人數成長帶來的部署問題

由於GitHub.com應用程式的貢獻人數，在去年成長了一倍，因此在部署程序出現了一些過去不曾遭遇的問題，對此GitHub決定將部署程序打散成為多階段，並且自動化部署程序，來解決部署混亂的問題。

雖然專案貢獻人數增加是一件值得高興的事，但是GitHub的部署工具也因此碰到了一些問題。GitHub.com主要透過ChatOps使用分支部署模型，也就是在Slack頻道中，讓開發人員以ChatOps的方式控制部署程序，在合併到主要分支前，先部署分支，也就是說，開發者可以在佇列中新增變更，檢查佇列狀態，組織要部署和合併的請求。

官方提到，雖然這是一個簡單的系統，但是由於一個頻道中，同時要管理多人的佇列、部署和各種任務，因此在監控部署上產生混亂，該頻道被大量訊息淹沒，使得開發人員無法透過系統追蹤變更，進而影響開發產能，並增加GitHub的風險。過去的部署方法存在幾個問題，第一個問題是，由於在Slack頻道內，一個部署會有許多相關的追蹤訊息，要將單一部署的不同訊息組合在一起並不容易，因為來自部署系統的後續訊息，可能多至數百條。

第二個問題則是發生在金絲雀（Canary）階段，在金絲雀階段最多只能部署GitHub.com的2％流量，也就是說，在100％部署的生產階段之前，有許多問題是在金絲雀階段無法被發現，一旦意外發生就需要回退，官方提到，可用性和正常運作時間（Uptime）是他們最在意的問題，因此隨著GitHub持續成長，改善這個問題變得非常重要。因此官方加入了第二個擁有更高流量百分比的金絲雀階段，讓GitHub.com能夠以較低的風險，過渡到100％的生產階段。

最後一個問題則是部署手續太麻煩，需要自動化程序讓部署更簡單。過去開發人員必須使用不同的指令排隊、部署到金絲雀階段，以及部署到生產階段，每個階段都需要人工參與，這讓開發人員不只需要學習ChatOps指令，並坐在電腦前等待部署工作結束，還很容易出錯。

因此GitHub展開了改善部署體驗，要讓開發者使用單一ChatOps指令，就能自動化整個部署程序，他們將部署切分成多個階段，並在不同階段間加入檢查機制，加以驗證程式碼部署結果，使整個系統如同狀態機一般運作。

自動化程序可以自動部署程式碼到2％金絲雀階段，接著是20％金絲雀階段，再來是部署到生產階段，最後則是準備合併，每個階段中間間隔5分鐘，指標會在每個階段完成部署後，自動指向下一階段。而部署的狀態，則從狀態機後端部署系統讀取資料，統一顯示在第一方使用者介面（下圖），這不只結合了開發者熟悉的傳統ChatOps，也讓開發者不需要在吵雜的Slack頻道中追蹤訊息。

開發者仍然跟過去一樣在Slack中開始部署，並且進行監控，官方提到，這還是開發人員最習慣的部署方式。這些調整改變了部署GitHub.com的方式，消除了因為太多貢獻者，對部署系統帶來的混亂。