🧨 何が起きたか
検証環境（STG）から本番前環境（PPR）に切り替えたはずなのに、
アプリが 検証環境サーバー に接続していました。
- ビルドは通る
- クラッシュもしない
- 見た目では違和感なし
しかし通信ログを見ると明らかに接続先がおかしい。
原因は pod install の実行忘れ でした。
🏗 前提構成
- 社内SDKを CocoaPods 経由で導入
- SDK側で環境（検証環境 / 本番前環境）ごとに接続先を切り替え
- 環境切替時に Podfile の参照リポジトリを切り替える運用
Podfile例：
# 検証環境
pod 'CompanySDK', :git => 'git@github.com:org/sdk-stg.git'
# 本番前環境
pod 'CompanySDK', :git => 'git@github.com:org/sdk-ppr.git'
❓ なぜ検証環境に接続したのか
理由は CocoaPodsの仕様とキャッシュ でした。
- Podfile.lockはブランチごとにコミット済み
- Podfileを書き換えただけでは依存は更新されない
- ローカルに古いPodsのキャッシュが残っていて、
pod installを忘れると旧環境が残る
つまり、個人の操作忘れが引き金でも、
本質的な原因は手動運用による仕組みの弱さ です。
🧠 実際の状況
- Podfile は本番前環境向けに変更済み
- Podfile.lock は更新されていたが、キャッシュの影響で検証環境版が残っていた
| 状態 | 実際の挙動 |
|---|---|
| コード | 本番前環境想定 |
| ビルド | 成功 |
| 実行時SDK | 検証環境版が読み込まれた |
- ビルドエラーは出ない
- クラッシュもしない
- 見た目では判別できない
→ 静かに間違うバグ です
🤖 人間の操作に頼る運用は危険
今回の事故は「忘れた個人が悪い」というより、
手動で環境切替・依存更新を行う仕組みそのものに原因があります。
- Podfile書き換え
- pod install 実行
- lock確認
毎回全員が確実にやる前提は現実的ではありません。
🛠 再発防止策（自動化）
1. 環境切替をスクリプト化
make switch-ppr
- 内部で Podfile更新・pod install実行
- 「忘れる」という選択肢を消す
2. CIで Podfile と Podfile.lock の不整合を検知
- Podfileが変更されたのにlockが更新されていないPRは失敗させる
- 個人依存を排除
3. SDK起動時に環境ログ出力
- SDK名
- バージョン
- 接続先（検証環境 / 本番前環境）
→ 起動時に確認できる
📌 学び
- Podfile.lockやキャッシュの影響で、Podfileを書き換えただけでは依存は更新されない
- 個人の操作忘れを前提とした運用は必ずどこかで事故る
- 人間が忘れても事故らない仕組みを作ることが最重要
🎯 まとめ
| 観点 | 結論 |
|---|---|
| pod install忘れ | 個人ミスではあるが本質は仕組み |
| 本質的な原因 | 手動運用に依存していた |
| 再発防止 | 環境切替スクリプト・CI検知・ログ出力 |
| 教訓 | 人を信用しない設計が安全 |
Podfile.lockがブランチごとに管理されていても、
キャッシュや手動操作に依存すると事故は起きます。
自動化することが最も確実な防止策です。