TODO
ソースコードレポジトリと CI ビルドの粒度をどうするか？
- ひとつのソースコードレポジトリ、ひとつの CI ビルド
- ひとつの巨大なレポジトリで全てのソースコードを管理し、 ひとつのビルドで全てのソースコードをビルドする。
- コードがチェックインされるたびにソースコード全体がビルドされ、 全てのマイクロサービスに対して verification ステップが実行され、 複数のアーティファクトが生成される。
- 基本的にこのパターンは避けるべき。
- 1行の変更でも全てのサービスがビルドされ verify される。 これは開発のスピードに悪影響を与える。
- ある変更をデプロイするためにどのサービスをデプロイすべきかがわからない。
- ある変更がビルドを壊してしまった場合、全てのサービスのビルドが止まる。
- ひとつのソースコードレポジトリ、サービス毎の CI ビルド
- ひとつの巨大なレポジトリで全てのソースコードを管理し、 ソースツリーの部分部分に対応する複数の CI ビルドを走らせる。
- 複数のサービスに対して同時に変更を加えるのが容易。
- サービス毎のソースコードレポジトリ、サービス毎の CI ビルド
- 著者が最もおすすめしているスタイル。
多くの技術スタックは、ある種の第一級アーティファクトを持っている。 Ruby なら gem, Java なら JAR, Python なら egg など。
しかし、マイクロサービスにおいては、このアーティファクトはそれ単体では十分でない。 JAR ファイルはそれ単体で実行可能にでき、埋め込まれた HTTP サーバを走らせることができるが、 Ruby や Python などは Apache や Nginx の中で走るプロセスマネージャを使いたいかもしれない。 (passenger のこと？)