はじめに
記録時点: 2024-03〜2024-04
この時期は、機能追加より先にデプロイ基盤を安定化していました。 環境を作り直して同じ結果が出ない状態で進むと、後続の開発効率が崩れるからです。
最初につまずいたのは依存関係
当時の失敗は、テンプレート記述ミスというより依存順序の揺れでした。
- 同じ変更でも適用順で成功と失敗が分かれる
- 失敗時のメッセージが抽象的で、根本原因にたどり着きづらい
- 手元では通るが、別環境で再現しない
この状態だと、修正より先に「誰の手順なら通るか」を探す作業が発生します。
先に潰したポイント
1. 初期テンプレートの責務を整理した
人手で補正していた設定をテンプレートへ戻し、手順依存を減らしました。 再作成時に同じ状態を作れることを優先しています。
2. 依存関係を明示し、順序依存を減らした
失敗が多い経路を洗い出し、依存の持ち方を調整しました。 結果として「たまたま通る」が減り、デプロイの成否が読みやすくなっています。
3. ステージ分離を早めに入れた
検証環境と本番相当環境の境界を先に作り、差分を追いやすくしました。 後から分離するより、運用ルールを揃えやすくなります。
当時の判断で悩んだ点
機能開発を優先して基盤整備を後ろに回すか
短期の進捗は出しやすいですが、後半で詰まるのが見えていたため見送りました。
一度に完全なテンプレートを目指すか
初期に完璧を狙うと実装が止まるため、事故の多い依存から段階的に整備する方針を取りました。
運用で固定した確認観点
- 新規環境で手作業なしに同じ構成を作れるか
- 依存リソース更新で成否が順序に依存しないか
- ステージ間の差分をテンプレート上で説明できるか
まとめ
2024年春は、CloudFormationを「1回通る道具」から「繰り返し使える基盤」へ変えた期間でした。 ここを先に整備したことで、以降の機能開発を止めずに進められています。