GitHub
V. ビルド、リリース、実行
ビルド、リリース、実行の3つのステージを厳密に分離する
コードベースは3つのステージを経て、（開発環境ではない）デプロイへと変換される。
- ビルドステージ は、コードリポジトリを ビルド と呼ばれる実行可能な塊へと変える変換である。デプロイプロセスで指定したコミットのコードで指定されたバージョンを使って、ビルドステージは依存関係を取得してローカル環境に配置し、バイナリやアセットファイルをコンパイルする。
- リリースステージ は、ビルドステージで生成されたビルドを受け取り、それをデプロイの現在の設定と結合する。出来上がる リリース にはビルドと設定の両方が含まれ、実行環境の中ですぐにでも実行できるよう準備が整う。
- 実行ステージ （ランタイムとも呼ばれる）は、選択されたリリースに対して、アプリケーションのいくつかのプロセスを起動することで、アプリケーションを実行環境の中で実行する。
Twelve-Factor Appは、ビルド、リリース、実行の3つのステージを厳密に分離する。 例えば、実行ステージにあるコードを変更してもその変更をビルドステージに伝える方法がないため、コードを実行中に変更することはあり得ない。
デプロイツールは通常、リリース管理ツールを提供する。中でも注目すべきは、以前のリリースにロールバックする機能である。例えばデプロイツールのCapistranoは、リリースをreleasesという名前のサブディレクトリに格納し、現在のリリースは現在のリリースのディレクトリへのシンボリックリンクとなる。Capistranoのrollbackコマンドを使うと、簡単かつ即座に以前のリリースにロールバックできる。
すべてのリリースは常に一意のリリースIDを持つべきである。リリースIDの例としては、リリースのタイムスタンプ（例：2011-04-06-20:32:17）や連番（例：v100）がある。リリースは追記専用の台帳であり、一度作られたリリースは変更することができない。変更する場合は新しいリリースを作らなければならない。
ビルドステージは、新しいコードがデプロイされるときに必ずアプリケーションの開発者によって開始される。一方実行ステージは、サーバーの再起動時や、クラッシュしたプロセスがプロセスマネージャーによって再起動された時に自動で開始される。このため、実行ステージはできるだけ可変部分を持たないようにするべきである。なぜなら、アプリケーションの実行を妨げるような問題が起きると、開発者が待機していない真夜中にアプリケーションが壊れる結果になるためである。ビルドステージはもっと複雑でも構わない。なぜなら、ビルドステージのエラーは常にデプロイを実行している開発者の目の前で発生するためである。