こんにちは、タイミーでバックエンドのテックリードをしている新谷 (@euglena1215) です。
このシリーズでは「モノリスRailsにマージキューを導入してデプロイフローを安定させる」の続編として、導入時のTIPSを紹介しています。前回は「GitHubマージキューTIPS：CIの実行を最適化し、障害対応を10分高速化する」について解説しました。
本記事では、GitHubのマージキュー導入後に発生した、ブランチ保護機能（Ruleset）のbypass list機能との非互換性について解説します。
これまでのコードフリーズ運用
タイミーでは、主に年末年始やGWといった開発者が少ない期間にコードフリーズ期間を設けています。この運用を実現するため、我々はGitHubのRulesetsと、そのbypass list機能を活用していました。
これは非常に便利な機能で、以下のような運用を可能にしています。
- 通常時： 開発者は自由にマージできる。
- コードフリーズ期間中： Rulesetを有効化し、原則マージを禁止する。
- 緊急時： ただし、bypass listに登録された開発者のみ、チェックボックス一つでこのルールを回避し、緊急の修正をマージできる。
この仕組みで、コードフリーズ期間中の安全性と、緊急時の柔軟な対応を両立していました。
マージキュー導入後に発覚した問題
マージキューを導入し、順調に運用が始まったかのように思えたある日、コードフリーズ期間直前に問題が発覚しました。
bypass listに登録されているにもかかわらず、ルールを回避してマージすることができなくなっていたのです。
コードフリーズ期間中にコードを変更することは基本ありませんが、例えば障害対応で緊急の修正が必要になった際に、これまでのように特定の担当者が即座にマージできなくなる、という影響が考えられます。これは、柔軟な対応を期待していた開発者にとっては意図しない仕様変更でした。
原因と対応
仕様上の非互換性
調査の結果、マージキューとRulesetのbypass機能は併用できないGitHubの仕様であることが分かりました。この件はGitHubの公式Discussionでも報告されています。
ref. https://github.com/orgs/community/discussions/45208
この仕様に対する直接的な解決策は見つからなかったため、bypass listを使用しない運用への変更が必要になりました。
新しい運用への変更
代替案として、以下の運用を構築しました。
- コードフリーズ期間中、常に失敗するCIジョブをワークフローに追加する。
- ただし、このCIジョブはブランチ保護ルールの必須チェックには設定しない。
これにより、開発者はCIの警告表示からコードフリーズ期間中であることを認識でき、意図しないマージの抑止につながります。
まとめ
GitHubのマージキューは有用な機能ですが、Rulesetのような既存の機能と組み合わせる際には、意図しない動作をしないか注意が必要です。（この記事は2025年7月時点のGitHubの仕様に基づいています。）
私たちのケースでは、導入後にこの問題が判明し、コードフリーズ直前の対応が必要となりました。
マージキューの導入を検討する際は、通常のデプロイフローだけでなく、コードフリーズのような特定の運用条件下でも意図した通りに動作するか、事前に検証することを推奨します。
特に、ご自身のチームが以下の点に当てはまるか、一度確認してみてください。
- ブランチ保護（Rulesets）で、特定の担当者やチームにマージの例外（Bypass）を許可しているか？
- その例外的なマージは、緊急時の対応など、今後も必要な運用か？
私たちのケースでは、導入後にこの問題が判明し、コードフリーズ直前の対応が必要となりました。
さて、次回はマージキューのポテンシャルを最大限に引き出すための「詰まり具合の可視化」と、パラメータチューニングについてご紹介します。
