nazolabo

なぞさんのブログ

ワンポイントTwelve-Factor App(1) : コードベース

この記事は、The Twelve-Factor Appを補足し、実際に現代的なWebアプリケーションで適用する場合の注意点などを紹介するシリーズです。下記の原文を読んだ上でのワンポイント解説になります。

12factor.net

概要

  • 単一のアプリケーション(システム)は単一のコードベースのみで成立する。
  • 単一のコードベースは単一のバージョン管理システムで変更を追跡している。
  • 環境によってコードを切り替えるようなことをしてはいけない。
  • 同一のコードを共有する複数のアプリケーションがある場合、それは依存関係管理ツールで管理する。

これは何を表しているか

「このアプリケーションはこのコードベースのみである」と明示しておくことによって、システムが明快になります。

これに違反しているというのはどういうことでしょうか。まず、「1アプリケーションが複数のコードベースで構成されている」というケースはどうなるでしょうか。それらのコードベースがそれぞれアプリケーションとして動作するものであれば、それは分散システム、現代的に言うのであればマイクロサービスみたいなものになります。その場合、各アプリケーションそれぞれが12Factor Appに即しているのであれば問題ありません。そうでない場合、システムが絡み合っているような状態になり、どこまでがどのアプリケーションなのかを把握するのが困難になります。

「複数のアプリケーションが1つのコードベース」というのは、ライブラリのようなものの場合になります。このような場合は、「どこまでがライブラリでどこまでがアプリケーションなのか」を把握するのが困難になるので、依存関係解決ツールを使用して明確に分離すべきです。

また、1つのアプリケーションを「ステージング」「本番」といった感じで複数の環境に配置する場合でも、必ず同一のコードをそれぞれの環境に展開するようにすべきです。「ステージングバージョン」「本番バージョン」というようなコードを作るべきではありません。これは「3. 設定」や「10. 開発/本番一致」などで重要になってきます。

実際に運用する場合

ここは書いてある通りですが、1アプリケーション=1リポジトリとし、外部ライブラリは依存関係解決ツールを利用しましょう。

前述の通り、「ステージング」や「本番」みたいな環境ごとで微妙に違うコードベース(ブランチなど)を用意するのもNGです。これらは設定で分離されるべきです。「3. 設定」で解説します。単一のコードベースでそれぞれの環境にデプロイすることで、環境間の

例外のケースとしては、OpenAPIやgRPCといった複数のアプリケーションにまたがる定義ファイルがあると思います。ただしこれらはそもそもプログラムではないので、いいのでないかという気はします。そこから生成されたコードはアプリケーションと同一リポジトリに格納しましょう。