CI/CD パイプラインを理解しよう

フラグとブランチ

継続的インテグレーションを導入する最初のステップは、コードベース全体を Git、Mercurial、Perforce といったバージョン管理システム（VCS、バージョン管理、または SCM）に投入し、チーム全員に変更の頻繁なコミットを習慣付けさせることです。 マスターにコミットされるたびに、パイプラインが開始し、コードのビルドとテストが行われ、作成したコードに関するフィードバックが迅速に提供されます。

頻繁にコミットすることは CI/CD パイプラインの重要なプラクティスですが、完成するまでに数日または数週間かかるような大規模な機能に取り組んでいる場合、そのプロセス中に定期的にコミットするのは両刃の剣のように感じられるかもしれません。

一定した増分で変更をパイプラインに押し進めれば、迅速なフィードバックを得られ、最後まで待つよりも競合が複雑化する可能性を低減させることができます。

一方で、中途半端な機能をユーザーにリリースしたり、ステージング環境で未完成のものを社内ユーザーに共有したりするのには億劫に感じられるかもしれません。

この問題については、機能フラグと機能ブランチで対処できます。 機能フラグは、コードがユーザーに公開される環境を指定するために使用できます。 変更はそれでもマスターにコミットされ、チームに公開されますが、その機能がステージングと本番にいつ公開されるかを決定することができます。

機能ブランチを使うと、機能を別のブランチで開発することができるため、自動ビルドとテストのメリットを損なうことがありません。 機能ブランチにコミットされるたびに、CI/CD パイプラインをトリガーすることで、マスターへのコミットと同様に、構築した内容に対するフィードバックを迅速に得ることができます。

コンテナーと VM

自動テストの結果に確実性を持たせるには、これらが一貫して実行することを保証する必要があります。

理想的に言えば、テスト環境はできるだけ本番に似せて構成されるべきであり、テストが実行されるたびに、環境上の矛盾によるテスト結果への影響を回避できるようにリセットされなければなりません。

仮想マシン（VM）はテスト中の新しいビルドごとにプロセスを初期化できるようにスクリプトすることができるため、長い間、テスト環境の実行に使用されてきました。

ところが、新しい VM を取り崩してスピンアップするには時間がかかる上、ソフトウェアが実行する必要のあるすべての依存関係を提供する仮想環境ごとの構成をスクリプトに含める必要があります。 新しい依存関係が追加されると、環境スクリプトも更新が必要となりますが、このような単純な作業は、ビルドが実行しない理由に悩まされるまで気づかないものです。

最初のビルドステップの一環として、コンテナーにコードをパッケージ化することで、この問題を回避することができます。 コンテナーにはソフトウェアが実行する必要のあるすべての依存関係が含まれるため、非常に移植しやすく、別の環境に簡単にデプロイすることができます。

独自のインフラストラクチャに CI/CD パイプラインをホストしている場合は、コンテナーをデプロイするための VM が必要となりますが、テスト環境の準備にかかる手間は少なくなるため、パイプラインの稼働を効率的に維持しやすくなります。 クラウドでパイプラインを実行している場合は、コンテナーを導入することで、マネージドサービスを使用できるようになり、インフラストラクチャ側の作業をクラウドプロバイダーに任せることができます。

デプロイ

コードの変更がパイプラインの手前の全ステージで合格すると、本番にリリースできるようになります。 その最終ステップは、手動ででも自動ででも行うことができます。

手動によるリリース（継続的デリバリー）は、新しい特徴や機能が公開される時期をあなたが制御する場合に役立ちます。デプロイプロセスによってユーザー側にダウンタイムが生じる場合や、製品がインストール済みであるため、変更をバッチ化して定期的なリリーススケジュールに合わせて提供する場合などに有効です。

完全に自動化された継続的デプロイプロセスでは、変更は、前のステージすべてで合格している限り、デプロイされて公開となります。

コードベースに関わっている開発者数とコミットの頻度によって異なりますが、このプロセスでは 1 日に数十回、更新がデプロイされる可能性があります。自動パイプラインがなけれは実質的に不可能なことです。