リリース1時間前だった。
ローカルでエラーが出た。検証環境では出ていないエラーが、なぜかローカルだけで出ている。おかしい。よく見ると——mainブランチに、いつのものかわからないコミットが大量に入り込んでいた。
「こんなの治せるわけない」
そう思った。
何が起きていたか
ベンダーからの引き継ぎが終わって間もない時期だった。まだgitの全体像を完全に把握しきれていない中で、定期リリースの準備をしていた。
ローカルで最終確認をしていたとき、検証環境では再現しないエラーが出た。環境の差異かと思って調べると、そうじゃなかった。mainブランチにあるはずのないコミットが100本単位で混入していた。 おそらくマージの順番を誰かが間違えたことで、過去のコミットが一気に流れ込んできたのだと思う。
コードは完全にカオスだった。どこからどこまでが正しい状態なのかわからない。revertを試みたが、コミットが絡み合いすぎていて、直すほど別の問題が出てくる。
時計を見た。リリースまで1時間を切っていた。
判断：mainブランチを捨てた
直すのに1時間かかるかどうかもわからない。でもリリースは止められない。
判断は早かった。mainブランチは放棄する。 カオスになったコードを直すより、クリーンな状態から作り直した方が速い。
検証ブランチは正常だった。そこからリリース用のブランチを切り直し、今回のリリースに含めるべき変更だけを手作業でマージした。mainは一旦捨てて、後で別途整理する。
# 検証ブランチを起点に、リリース分だけ切り出す
git checkout -b release/hotfix origin/staging
git cherry-pick <リリース対象のコミットのみ>1時間でなんとか形にした。リリースは通った。ユーザーへの影響はゼロだった。
誰にも理解されなかった
作業中、周りに説明しようとは思わなかった。
運用担当の人間も、他のメンバーも、この状況の重大さを理解できる人間はいなかった。リテラシーの問題ではなく、gitの内部で何が起きているかを把握するには、相応の経験が必要だ。説明するだけ時間の無駄だし、説明したところで「大変だったんだね」以上の言葉は返ってこない。
黙って、一人でやった。
終わった後、ベンダーの担当者にこっそり話した。引き継ぎの時期に世話になった人だ。その人だけがこの話の重さを理解してくれた。
「自分かっこいい」と思わないとやってられない
リリースが終わったあと、一人でそう思った。
ユーザーへの影響をゼロで食い止めた。誰もこの修羅場を知らない。評価されることもない。でも、やり切った。
自分くらい自分を褒めてあげないと、誰も褒めてくれないのだから。
この経験で学んだことが一つある。カオスに陥ったとき、「直す」以外の選択肢を持っておくことだ。mainブランチを放棄するのは怖い判断に見えるが、「クリーンな状態はどこか」を把握できていれば、そこから切り直す方が速いことがある。
治すより、捨てて作り直す。それを1時間で判断できたのは、この経験以来、自分の中に残っている考え方だ。