理想のステージ設計のメモ
GitHub を使ってシステムの開発を行う際の理想のステージ設計のメモです。
用意するステージ
- production 環境
- development 環境
- feature 環境
各ステージの役割
共通事項
- データベースなどのシステムが利用する外部リソースは全ての環境で独立しています。
- 利用する外部リソースもコードで管理されており、GitHub にプッシュすると自動的に対応する環境にデプロイが行われます。
production 環境
- ユーザーに提供される環境です。
- master ブランチにマージされたらこの環境に自動的にデプロイされます。
development 環境
- ユーザーに提供されない環境です。
- リリース前に最終確認を行うための環境です。master ブランチとのマージを強制する目的があります。
- データを含めて production 環境と限りなく近づけますが、個人情報はマスクされています。
- develop ブランチにマージされたらこの環境に自動的にデプロイされます。
feature 環境
- ユーザーに提供されない環境です。
- データを含めて production 環境と限りなく近づけますが、個人情報はマスクされています。
- master ブランチと develop ブランチ以外のブランチにプッシュされたら、それぞれのブランチに対応する feature 環境に自動的にデプロイされます。つまり、feature 環境の数は master ブランチと develop ブランチ以外のブランチの数と一致します。
- バックエンドに AWS や GCP のようなクラウドのリソースが利用されていても、全ての feature 環境ごとに作成されます。インフラストラクチャーの構成の変更も各 feature 環境で検証することができます。
開発フロー
- develop ブランチからチェックアウトして新しい開発用のブランチ(feature 環境)を作成します。
- 各 feature 環境で動作確認が完了したら、develop ブランチにマージします。
- develop ブランチで問題が見つからなければ、master ブランチにマージします。
