以前のWebシステムでは、Perl、PHP、Ruby、Python、Nodeといった動的型付け言語を用いて実装されたシステムが多かった。動的型付け言語では通常ビルドという作業は行なわれず(動的にコンパイルを行うこともある)、ランタイムがあるサーバーにソースコードをそのままコピーし、必要に応じてプロセスを再起動することでデプロイとしていた。静的型付け言語の多くはこの手法とは異なり、成果物をビルドすることで実行可能ファイルを生成し、それをサーバーにコピーし必要に応じてプロセスを再起動する。この実行可能ファイルのように、機械によって生成された何かの事を生成物と呼ぶことにすると、動的型付け言語と静的型付け言語では、生成物の有無も違いの一つと言える。しかし動的型付け言語を使用していたとしても、近年ではコンテナ技術が普及し、Docker Imageをビルドし、それをデプロイするようなシステム構成も増えた。このDocker Imageも成果物と考えられる。また近年ではWebのフロントエンドで動作するJavaScript(TypeScriptなどを含む)やCSS(SaSSなどを含む)を始めとしたコードも、トランスパイルやミニファイされるようになった。これらも生成物と考えることができるし、実際にそう呼ばれている。今回は、これらの生成物をいつ、だれが、どのタイミングで、生成及びテストし、デプロイするんことが最適かということを考えた。
- 成果物は必ず1度だけ生成する。
- 成果物は必ずデプロイするものと同じものをテストする。
成果物には本番環境にデプロイされるものと、そうではないものが存在する。それらが混在すると成果物の管理が難しくなるため、成果物のリポジトリは本番用と開発用の2種類を用意する。本番用の成果物リポジトリは開発用のリポジトリとある程度同期させ、開発用の成果物リポジトリ内の梱包物の内、特定のマーカーが付いたものだけをコピーする。
開発用リポジトリ 本番用リポジトリ
+--------------------------+ +----------------+
|{s} | |{s} |
| | | |
| +------------+ | | |
| | Articact A | <--+ | | |
| +------------+ | | | |
| | | | |
| +------------+ | | COPY | +------------+ |
| | Articact B |-(OK)<--+ |--------------------------->+ | Articact B | |
| +------------+ | | ^ | +------------+ |
| | | | | |
| +------------+ | | | | |
| | Articact C | <--+-------+ | | |
| +------------+ | | Testing | | |
| | | and | | |
| | | Add ok label | | |
+-----+------------+-------+ | | +----------------+
^ ^ | |
| | | |
| Build | Build | |
| and | and | |
| Put | Put | |
| | | |
+------------+ +--+------------+--+ +--+---------+
| Developer | | CI | | CD |
+------------+ +------------------+ +------------+このような構成では本番用リポジトリには常に本番へのロールアウトの実績が存在する成果物のみが保持されることになる。とても綺麗な状態となり、開発者やその他の関係者の認知的負荷を下げることができる。