GitHubエンジニアリングチームは最近、デプロイアプローチをどのように再設計したかについてブログを書いた。エンジニアリングの急速な成長により既存のツールにいくつかの問題が発生したためである。
GitHubのシニアソフトウェア開発者であるJulian Nadeau氏が、GitHubでの刷新されたデプロイメントエクスペリエンスの概要を説明した。1年前、GitHubは、ChatOpsを使用したブランチデプロイモデルを採用して、メインブランチにマージする前に変更をリリースした。開発者はSlackチャネル（#dotcom-ops）を使用して、変更をキューに追加し、キューのステータスを監視した。チームメンバーの数が増えると、同Slackチャネルでのデプロイに関するメッセージも増えた。
Canaryステージを利用して、コードの変更は最初に2％のGitHub.comユーザにリリースされ、次に100％のユーザにリリースされた。つまり、100％のトラフィックにリリースする前に、リリースに関するすべての問題をキャッチできるとは限らなかった。最終的に、インシデントがオープンされ、ロールバックする必要が生じた。
GitHubチームの成長に伴い、上記のマルチステップで情報量の多いChatOpsデプロイプロセスの課題がより顕著になった。GitHubエンジニアリングチームは、2つの問題領域を特定した。それは、デプロイの変更を監視することと、初期のリリースステージでより多くの問題をキャッチすることであり、それによって本番インシデントの影響範囲を最小限に抑える。
これらの問題に対処するために、チームは、デプロイシーケンスを開始する単一のChatOpsコマンドと、特定のデプロイの概要を提供するユーザインターフェイス（UI）を考案した。
出典: https://github.blog/2021-01-25-improving-how-we-deploy-github/
トラフィックの20％で2番目のカナリアステージが導入され、100％の本番ステージでリスクが軽減された。上の図に示すように、ステージはタイマーによって5分間で自動で分離され、デプロイを一時停止してテストにより多くの時間を与えることができる。タイマーの完了後、ポインターが自動的に各ステージを通過する。
以下のUIは、Slackチャネルの積み重なったメッセージとは対照的な、デプロイメントの概要を示している。上の図でハイライトされているステージは、右側に表示される。
出典: https://github.blog/2021-01-25-improving-how-we-deploy-github/
システムはSlackから監視し、起動できるため、開発者がデプロイシステムとインタラクションする方法に対して、変更を最小限に抑えることができる。
Hacker Newsの技術コミュニティはこれに注目し、興味深い会話を引き起こした。
会話スレッドで、プルリクエスト（PR）がカナリア、本番環境にデプロイされ、その後、GitHubでマージされるというアプローチが十分に検討された。一般に公開する前に最初にマージするものとは対照的なものである。スレッドでは、エンジニアリングマネージャーのBrooks Swinnerton氏から反応があり、GitHubフローについて説明され、GitHubのHubotについて言及があった。
別のスレッドでは、Slackベースのデプロイメントシステムの使用を、CircleCIやJenkinsと比較した。
このスレッドで、ユーザXorlevは、「...カナリアステージはわずか5分です。多くの問題が現れるまでに時間がかかります。これは、かなり危険なリリースプロセスのように思います。」とコメントしている。Nadeau（jules2689）は、時間と期間のバランスを取る必要性を強調する複雑な反応をした。
GitHubエンジニアリングチームは、この自動化されたシステムに関して多くの肯定的な内部フィードバックを得た。このブログ投稿は、Building GitHubブログシリーズの一部であり、GitHub Engineering Organizationの詳細を提供している。InfoQは以前にこのシリーズの記事を提供した。