twelve-factor app とは？クラウドネイティブなサービスの原則

twelve-factor app とは、可搬でスケーラブル、そしてデプロイしやすい software-as-a-service を構築するための、12の原則からなる方法論です。

Heroku のエンジニアが公開した twelve-factor app は、サービスをクラウドに適したものにする実践を体系化しています。宣言的なセットアップ、config とコードのきれいな分離、そして使い捨てで stateless なプロセス。その factor の多くは、CI/CD できれいにデプロイできるサービスのチェックリストのように読めます。それこそが、これらが今も生き続ける理由です。

中核となるテーマ

12の factor はいくつかの考えに集約されます。config をコードの外に置く、backing service を接続されたリソースとして扱う、build と run を別々のステージにする、アプリを stateless で使い捨てのプロセスとして動かす。これらが合わさって、サービスをデプロイし運用しやすい予測可能なものにします。

CI/CD に最も関連する factor

Codebase: version control で追跡される1つの repo、多数の deploy。
Config: config をコードではなく環境に格納する。
Build, release, run: これらを厳密に別々のステージに保つ。
Processes: stateless で share-nothing なプロセスとして動かす。
Dev/prod parity: 環境をできる限り似せて保つ。

環境の中の config

twelve-factor は、設定、認証情報、環境ごとの値を build の外、環境の中に保ちます。それこそが、不変の artifact を変更せずに staging から本番へ昇格できるようにするものであり、クリーンな delivery pipeline の礎石です。

build、release、run の分離

CI/CD に最も直接対応する factor です。build は artifact を生成し、release はそれを config と組み合わせ、run はそれを実行します。これらを分離しておくことは、テストしたまさにその artifact を実行することを意味し、環境間での rebuild がありません。

使い捨て可能性と parity

stateless で起動が速く使い捨て可能なプロセスこそが、horizontal scaling と rolling deploy を機能させます。dev/prod parity は、パイプラインの環境を本番に近く保つことで「CI では動くが本番で失敗する」という差を減らします。

マネージド runner への自然な適合

twelve-factor の使い捨て可能性は、CI がどう動くべきかを映しています。ジョブごとにクリーンで同一の使い捨て環境です。エフェメラルなマネージド runner（Latchkey が提供するもの）は、build ステージそのものに同じ原則を体現します。

重要なポイント

twelve-factor app は、可搬でデプロイしやすいクラウドサービスのためのチェックリストである。
config を環境に置くことと build/release/run の分離は、クリーンな CI/CD に直接対応する。
stateless で使い捨てのプロセスこそが、スケーリングと rolling deploy を可能にする。