緊急事態

緊急の場合は、CLに対してより迅速に、レビューを通過させる必要がある。

緊急事態とは？

緊急レビューが許可される状況は次の通りである。ロールバックを行わずに重要なリリース日に合わせるようにする時、実際のユーザーに大きな影響を与えるバグ修正が必要な時、緊急の法的問題を解決する時、重大なセキュリティホールを解決する時などだ。

緊急事態では、レビュアーの応答速度よりは、実際にレビューが通過される時間を速くする必要がある。CLが本当に問題を解決するか、そしてレビューがどれだけ早く通過できるかを重要視する。そして当然ながらも、他のレビューより優先されるべきである。ただ、緊急事態が解消された後、そのCLは再び厳格なレビューを経る。

緊急事態ではない時は？

次の場合は緊急事態ではない。

• 単にリリーズ日を一週間早めたい時（契約書上に強制されるのではない時）
• 長い間作業していた機能なので、今度はレビューの承認を受けたい時
• 他の時間帯のレビュアーが勤務中でない場合、または出張中の場合
• 今日が金曜日の夜だから、週末前にマージさせてほしいと思った時
• 過去に定められた締切期限（soft deadline）を守るためにマネージャーが強要した時
• テスト失敗やビルド失敗を引き起こすCLを元に戻す時

など

厳格な締切（hard deadline）とは？

厳格な締切とは、締め切りを過ぎると絶望的なことが起こる場合を意味する。例えば、

• 契約書上の義務を守らなければならない時
• 特定の時点まで市場に発売できない時
• 完全に台無しになる時、あるハードウェアメーカーは製品発売日が年に一度である。もしこれまでコードを送らなければ、災害のような事態が起きる時

発売を一週間遅らせたり、重要なコンファレンスを見逃すことは、そんなに深刻な出来事ではない。ほとんどの締め切りはsoft deadlineである。重要ではあるが、コードの品質をあきらめる程度ではない。また、製品の発売間隔が長ければ、開発者としては更に数週間待つことが嫌なのでレビューを早く終わらせたいが、このようなことが繰り返されると技術負債が耐えられないほど大きくなる。また、締切期限に近づいてこそ開発者がCLを提出して十分にレビューをする時間がいつも足りない場合、開発プロセスを再整備するようにする。