GitHubエンジニアリングチームは最近、高速で信頼性の高いデプロイを保証する方法についてブログに書いた。GitHubのソフトウェアエンジニアであるRaffaele Di Fazio氏は、GitHubのデプロイメントメカニズムについて深く掘り下げた。
GitHubは、複数のKubernetesクラスタと物理サーバにデプロイされる。デプロイプロセスはGitHubの顧客と内部ユーザに影響を与えるため、デプロイの信頼性を保護することはチームにとって重要であった。GitHubエンジニアリングチームは、問題領域を完全に理解するために、デプロイツールからデータをフェッチすることから開始した。
- CI/CDビルド期間
- デプロイパイプラインの個々のステップの期間
- デプロイパイプラインの合計期間
- デプロイパイプラインの最終状態
- ロールバックされたデプロイの数
- パイプラインのいずれかのステップで発生したデプロイのリトライ
チームはまた、プルリクエストがマージされるのにかかる時間や、デプロイ/マージされたプルリクエストの数など、いくつかの一般的な指標を分析した。収集されたこれらの指標の多くは、Forsgren et alの「Accelerate」で示された4つの主要な指標と一致する。それは、低、中、高のソフトウェアデリバリの実行者を区別するものであり、リードタイム、デプロイ頻度、平均修復時間（MTTR）、変更の失敗率である。
顧客向けのGitHubはKubernetesにデプロイされるモノリシックなRuby on Railsアプリである。そのため、チームは新しいバージョンをデプロイするときに複数のKubernetesクラスタでポッドを起動する必要がある。ブログでは、デプロイツールが多くの情報を提供しなかった状況を挙げており、問題解決のためにKubernetesを調べることが重要になっている。
「私たちはツールに変更を加えており、それによって展開中のデプロイに関するより良い情報を提供します。そして、障害が発生した場合に特定の下位レベルの情報を能動的に提供します。これには、Kubernetes自体に直接アクセスすることなくKubernetesイベントの閲覧することも含まれる。」
GitHubエンジニアリングチームは、デプロイに対するいくつかのサービスレベル目標（SLO）の追跡も開始した。Webアプリケーションの成功率または遅延時間にSLOを使う従来の方法と異なり、SLOを使用したこのアプローチにより、チームは本番デプロイプロセスの改善にフォーカスを移すことができた。
Danyel Fisher氏とLiz Fong-Jones氏による最近のフェイルオーバー会議の講演であるSLOの測定における落とし穴で議論されているように、こういったデータの収集と分析は簡単ではない。Googleサイト信頼性エンジニアリングの本（オンラインで無料で入手可能）は、より深く学びたい読者にお勧めの出発点である。
GitHubでは、専任チームがアプリケーションの継続的デプロイを担当し、アプリケーションのデプロイとベストプラクティスの開発を支援する。SLOは、チームが優先順位を付けて、特定の日に、より多くの機能を確実にリリースし、デプロイを改善する支援をする。
Building GitHubブログシリーズでは、GitHubエンジニアリング組織について詳しく説明し、組織全体のチームが舞台裏でどのように協力しているかを示している。シリーズの投稿は2020年第3四半期に始まった。シリーズの前回の投稿では、チームがgithub.comでのデプロイエクスペリエンスをどのように改善したかについて掲載されている。