はじめに
本連載はソフトウェアデリバリーにおける継続的デリバリー・プログレッシブデリバリーについての連載で、以下の3つの記事で構成されています。
第1回となる本記事では、継続デリバリーについての概要、話題となっているGitOpsは何か、どんなメリットがあるのか、現在のGitOpsソリューションについて紹介します。
第2回では、プログレッシブデリバリーの解説と各ソリューションの紹介・比較について説明します。
第3回では、実際にPipeCDを活用し、インフラストラクチャからアプリケーションの継続的デリバリーの実践方法について紹介します。
継続的インテグレーション（CI）と継続的デリバリー（CD）の違い
ソフトウェア開発者は、ソフトウェアの変更を日常的にコミットしています。その変更は、素晴らしいアイデアに基づいた大きな機能追加や、小さなバグ対応の場合もあります。そのような変更をユーザーへ反映するプロセスはソフトウェアデリバリーと呼ばれ、以下のことを目指しています。
- 変更点を出来るだけ早くユーザーへ届ける
- 変更点へのフィードバックを出来るだけ早くもらう
これらのためにデリバリープロセスの速度や精度を向上させる必要があります。それだけでなく、コストやリスクを下げるためにも、人間が手動で行っている部分を自動化していくことが求められています。CI/CDはその自動化プロセスの一部を担っており、モダンな開発プロセスには不可欠な存在となっています。
CI/CDはひとくくりとして捉えられることが多いですが、CIとCDは全く別の役割を担っているため、別々のシステムとして動かすようになってきています。
CIとはContinuous Integrationの略で、継続的インテグレーションと呼ばれています。CIの主な目的は、開発者がコミットした変更点に対して以下のアクションを行うことです。
- 自動的に初期のフィードバックを返す
- 生成物としてアーティファクトを作成・保存する
初期のフィードバックとは、システムのビルド・テスト・規約チェックなどのタスクを実行することで早めにバグやコード品質に関する検証結果を開発者に提供することです。全ての検証が通ったら、CIのアウトプットとしてアーティファクトを作成して、ストレージに保存します。アーティファクトとは色々な種類があり、アプリケーションの場合は最近Dockerイメージがよく使われていますが、各開発言語のバイナリファイルも使われています。インフラ構築や設定のコードの場合のアーティファクトはTerraform Moduleなどが多いです。クラウドネイティブアプリケーションの設定ファイルは、HelmのChart、KustomizeにおけるKustomizationファイルなどです。
一方、CDとはContinuous Deliveryの略で、継続的デリバリーと呼ばれています。CDは、CIから生成されたアーティファクトを特定のリリースプロセスに準じて、アプリケーションのユーザーに対し変更点を反映します。こうすることで、ユーザーへ新たな価値を提供できます。CDプロセスでは以下のことを目指しています。
- 変更点を迅速にユーザー側へ反映すること
- リスク・変更点のネガティブなインパクトを小さくすること
CDは継続的デプロイ（Continuous Deployment）という概念もあり、継続的デリバリーの次のレベルだと言われています。前述した継続的デリバリーは厳密には完全な自動化は見込めません。継続的デリバリーはCIを通過してもビジネス要件等の都合によりリリースタイミングは人間によって決定されます。一方で継続的デプロイではCIさえ通れば、明示的な承認なしで自動的に運用環境へデプロイされます。つまり、新しいアーティファクトが生成されると人間の介入なしで自動的にデプロイ・リリースされます。
継続的デリバリーは色々な面で進化しています。以前は専用の運用チームで手動リリースしたり、CIシステムでリリースタスクを作成して行ったりする方法がよく採られていましたが、PipeCD、FluxCD、ArgoCD、Spinnakerなどの専用CDシステムが使われるケースも増えてきています。これらのCDシステムは、GitOpsというモデルを採用していることが共通点として挙げられます。
次項からは、GitOpsについて説明します。
