この記事は、The Twelve-Factor Appを補足し、実際に現代的なWebアプリケーションで適用する場合の注意点などを紹介するシリーズです。下記の原文を読んだ上でのワンポイント解説になります。
概要
- 単一のアプリケーション（システム）は単一のコードベースのみで成立する。
- 単一のコードベースは単一のバージョン管理システムで変更を追跡している。
- 環境によってコードを切り替えるようなことをしてはいけない。
- 同一のコードを共有する複数のアプリケーションがある場合、それは依存関係管理ツールで管理する。
これは何を表しているか
「このアプリケーションはこのコードベースのみである」と明示しておくことによって、システムが明快になります。
これに違反しているというのはどういうことでしょうか。まず、「1アプリケーションが複数のコードベースで構成されている」というケースはどうなるでしょうか。それらのコードベースがそれぞれアプリケーションとして動作するものであれば、それは分散システム、現代的に言うのであればマイクロサービスみたいなものになります。その場合、各アプリケーションそれぞれが12Factor Appに即しているのであれば問題ありません。そうでない場合、システムが絡み合っているような状態になり、どこまでがどのアプリケーションなのかを把握するのが困難になります。
「複数のアプリケーションが1つのコードベース」というのは、ライブラリのようなものの場合になります。このような場合は、「どこまでがライブラリでどこまでがアプリケーションなのか」を把握するのが困難になるので、依存関係解決ツールを使用して明確に分離すべきです。
また、１つのアプリケーションを「ステージング」「本番」といった感じで複数の環境に配置する場合でも、必ず同一のコードをそれぞれの環境に展開するようにすべきです。「ステージングバージョン」「本番バージョン」というようなコードを作るべきではありません。これは「3. 設定」や「10. 開発/本番一致」などで重要になってきます。
実際に運用する場合
ここは書いてある通りですが、1アプリケーション=1リポジトリとし、外部ライブラリは依存関係解決ツールを利用しましょう。
前述の通り、「ステージング」や「本番」みたいな環境ごとで微妙に違うコードベース（ブランチなど）を用意するのもNGです。これらは設定で分離されるべきです。「3. 設定」で解説します。単一のコードベースでそれぞれの環境にデプロイすることで、環境間の
例外のケースとしては、OpenAPIやgRPCといった複数のアプリケーションにまたがる定義ファイルがあると思います。ただしこれらはそもそもプログラムではないので、いいのでないかという気はします。そこから生成されたコードはアプリケーションと同一リポジトリに格納しましょう。
