はじめに
本記事は、先日初めてリリース作業を行った初心者エンジニアが書いています。
この記事を読んでいる人の中には「リリース後にバグが見つかっちゃった...でもどうやって修正したら良いの？」という経験があったり、今、実際にその状況に陥っていたり...といった方もいると思います。
10月某日、自身のエンジニアチームでは、上記のような状況に陥った場合に冷静に対処できるよう「チーム開発において、リリースに失敗した時の対処法」について「避難訓練」と称した実践形式の勉強会を行いました。
そこで本記事では「本番環境を元の正常動作に戻す」という観点に沿って、学んだことをまとめました。
推奨の対処法
1. デプロイロールバック
本番環境を正常に動いていた直前のリリースの状態に戻し(ロールバック)、地道にfixします。
2. git revert + 再デプロイ
git revert <option> <commitのハッシュ値>
revertは指定したコミットを打ち消すようなコミットを新たに作成するコマンドです。
コミットログが残ります。ありがたいですね。
一方、コミットを一つずつ取り消すので、コミット数が多い時は不便です。
また、一括で複数のコミット履歴をrevertすることもできますが、チーム開発の場合は、他のメンバーのコミット履歴もrevertしてしまう危険性があります。
そのため、チーム開発においてrevertする場合は、慎重に事を運ぶ必要があるので注意しましょう。
補足：マージコミットをrevertした場合
マージ履歴が残っているため、マージ元のブランチからマージ先のブランチに再マージできません。
そのため、revertして作成された打ち消しコミットを打ち消すためのrevertが必要になります。
非推奨の対処法
git reset + 強制プッシュ
git reset <option> <commitのハッシュ値>
resetは指定したコミットまで巻き戻してくれるコマンドです。
ただし、revertと違ってコミットログが残りません。
また、一度リモートに上がったコミットをresetで削除した場合、そのブランチをプッシュする際は強制プッシュをする必要があります。
masterブランチに強制プッシュをすると、他のメンバーのローカルのmasterブランチとコミット履歴が一致しなくなってしまう可能性があります。
こうなってしまうと、チーム開発に大きな支障が出ます。
そのような状況は避けたいですね。絶対にやめましょう。
補足：resetの使いどころ
プッシュしていないコミットを削除する時や他の人が触らないとわかっているブランチ(個人のfeatureブランチなど)で作業する時に使う分には良さそうです。
結論
本番環境を元の正常動作に戻す方法はいくつかありますが、自身の開発環境に合わせて適宜使い分けるとGOOD.
避難訓練を行った感想
実践形式で学べて良かったです。
一人で開発をしていると「コマンドを叩いてリセットしよ🎵」で済ませてしまうかもしれません(少なくとも私はそうです)。
しかし、チーム開発になると話は別です。
今回、チーム開発においてリリース失敗時にやってはいけないこととやったほうがいいことを知ることができたので、これから実務でしっかり活かしていきたいと思います。
チーム全体として「やってよかった」の声が上がったのも好印象です。
ぜひ一度、自身のチームで避難訓練を行ってみてはいかがでしょうか？