CIは緑なのに本番だけ壊れる——個人開発アプリの2つの事故
個人開発のiOSアプリで、ログイン全滅とセキュリティ修正の未反映という2つの本番事故が起きた。どちらもCIは通っていた。原因と、足した確認の仕組みをまとめた記事。
#なぜ今日これを選んだか
個人でiOSアプリを作っていると、テストとCI/CDは「そのうち整える」ものになりがちだ。でもこの記事の事故は、CIを整えていたのに起きている。CIが通ることと、本番に正しく届いていることは別の話だという点を、具体的な事故で確かめられるのが良かった。
#要点
- 事故1: 本番用のFirebase設定ファイルが仮の値のまま提出され、本番アプリでログインとApp Checkが全滅した。開発を楽にするための「ファイルが無ければ代わりで進める」仕組みが、提出時にもそのまま働いたのが原因。配布前に「ファイルがあるか」だけでなく「中身がサンプルのままでないか」まで見る確認を足した
- 事故2: セキュリティ修正をマージしたのに、本番のコンテナは修正前のイメージのまま数日動いていた。最初の「今回はAPIの再ビルドは要らない」という判断を、後から入った修正にも引きずったため。ArgoCDの警告で気づいた
- 落とし穴が2つ。DockerfileでARGを宣言するだけではKanikoのキャッシュが変わらない（RUNで実際に使う必要がある）。docker composeのproject名を指定しないとフォルダ名が使われ、ローカルでは別のイメージを検査して「手元は緑・本番は赤」になる
#自分にとっての示唆
一番刺さったのは「一度出した『影響なし』の判断を、後の変更にも使い回してしまう」という事故2の構造だ。テストをモックで固めるほど、本番の設定や環境の抜けはCIから見えなくなる。2つの事故はどちらも、「作ったもの」ではなく「届いたもの」を見ていなかったのが原因だと思う。明日からの行動は1つだけ。個人開発のアプリをビルドするとき、最後に「いま端末で動いているのは、どのコミットのビルドか」を画面のどこかに表示するようにする。届いたものを自分の目で確かめる入口はここからだ。