たまにソフトウェアを開発してリリースしていく流れで「動作確認どうしますか」という相談が始まることがあります。具体的には、「手元環境や開発環境で十分確認したのでこのまま本番に出していきましょう」とするのか、「本番環境でも前もって確認したいので、一部のメンバーだけ見られる状態で確認してから全員に解放しましょう」とするのか、みたいな話。
この話が出るのは大体の場合、新機能開発というより既存の機能のちょっとした改良のときです。ちょっと改良しただけだからFeature Flagのようなものは使っていなくて、でも出す直前になってやっぱり本番で一部メンバーに限定解放してから出したほうがいいんだろうかみたいな流れです。
この際に、「コスパどうですか」という話になりがち。「限定解放をサクッとやれそうならやればよいですね」とか、「そもそも今回の改修内容は環境差異によって問題が起きそうなんでしょうか、確認したい項目はどこですか。そこに限定して確認したらサクッと終わりませんか」とかそういう感じの話になります。
理想の状態は何なのか
コスパを見極めて判断するというと聞こえはいいですが、こういうことを毎回判断して決めてるのは理想な状態じゃない気がします。
「出す直前になってやっぱり本番で一部メンバーに限定解放してから出したほうがいい」という気持ちになっている原因を考えていくとよいと思っておもむろにこの記事を書いています。
理想な状態はSLOを割らない程度に爆速でリリースしていって、問題が起きたら爆速で対処できる状態だと思います。バグを常にゼロにすることはできませんが、復旧時間を短くすることは可能です。Feature Flagは確かに使っていけばいいと思いますが、実際には何でもかんでもFeature Flagにするわけではないと思います。そういう使っていない箇所についてはデプロイや切り戻しを爆速でやれれば不安は減るはずです。また、毎度毎度人間がそれぞれの環境で動作確認をし続けるコストを減らしたい（人間が確認してるうちは漏れも発生しうる）ので、やれるところから自動テストにしていきたいですね。
つまり、リリース速度が爆速で問題が起きても即座に対応できる、動作確認も自動化されている、となっていればちょっとした機能を出すときに不安を感じたり動作確認にかかるコスパを考えはじめるみたいなのは減らせるはずですね。
この記事は すてにゃん Advent Calendar 2023 - Adventar の18日目の記事です。
