この記事は、The Twelve-Factor Appを補足し、実際に現代的なWebアプリケーションで適用する場合の注意点などを紹介するシリーズです。下記の原文を読んだ上でのワンポイント解説になります。
概要
- ビルドはコンパイル（ビルド）・依存関係の解決など
- リリースはビルド結果に設定を足す
- 実行はプロセスの起動
- これらを全て明確に分離する
これは何を表しているか
「1. コードベース」で定義されたコードは、単一のビルドと対応します。ビルドでは依存関係解決ツール（「2. 依存関係」参照）での依存関係解決などを行います。この時点では実行環境に固有の設定（「3. 設定」参照）は登場してはいけません。
ビルドに対し、「3. 設定」で定義された設定を組み合わせたものが、単一のリリースとなります。リリースは一意の名前を持っており、変更することができません。変更するには追記する必要があります。
リリースされたものは実行ステージで実行されます。実行ステージではサーバーの再起動やクラッシュ時に自動で再起動したりするようなことがあるので、ここでは余計なことはせずに最小限の動作のみにしておく必要があります。ビルドステージでのエラーは実環境に影響を与えないので捕捉が簡単ですが、実行ステージは既に外部サーバーで動いているのでエラーの捕捉が困難です。
これらの作業が確実に分離されていることによって、他の項の条件も満たしやすくなり、構造も明確になります。
実際に運用する場合
ビルドはCIサービスで行われます。ビルドになるべく複雑な内容を入れておくことで、ビルドに失敗するとCIがエラーを返してくれ、リリース前に問題を検知することができます。
テストもCIサービスのビルド（厳密にはビルドとリリースの間）ステージに入れておくことで、同様にCIがエラーを返してくれます。ビルドはコードベースに対して単一で、その成果物に対してテストをすることで、「テストが通ったのに本番で動かない」という状況を回避することができます。Dockerコンテナとしてビルドしたものに対して docker run でテストをすると、ビルドの成果物に影響を与えずテストだけ行うことができます。
リリース及び実行はデプロイ環境によって様々ですので、各環境に合わせて構築してください。
