CI/CDとは？CI/CDパイプラインとツールを解説
著者
0 分で読めます
CI/CDは、この数十年でニッチなテーマから、ソフトウェア開発とデリバリーにおける主流のアプローチへと変化し、業界では当たり前のものとして定着しました。多くの人が自信を持ってこの言葉を使っていますが、CIとCDの正確な意味は誤用されたり、誤解されたりすることが少なくありません。
CI/CDを解説
CI/CDとは？
CI/CDは、ソフトウェア開発で広く使われている略語です。「継続的インテグレーション」と「継続的デリバリー」を意味します。これらは異なる概念ですが、ひとつのものとして扱われることも少なくありません。
継続的インテグレーションとは、開発作業が完了しているかどうかにかかわらず、プロジェクト内のすべてのコードを定期的に単一のブランチにコミットする、標準的な開発プロセスです。
継続的デリバリーとは、コードベースの成果物を構成するデプロイ単位を定期的にパッケージ化するプロセスです。これらのプロセスは、開発の自動化やDevOps、そして近年ではGitOpsと関連付けられることが一般的です。
CI/CDパイプラインの主な構成要素とは？
継続的インテグレーション（CI）とは？
継続的インテグレーション（CI）とは、開発中のコードを定期的に統合して、1つのブランチにまとめる開発手法です。このブランチは通常「トランク」と呼ばれます。特定の理由（稼働中のシステムにホットフィックスを適用する場合など）でチームがブランチを作成することはありますが、こうしたケースは原則に対する例外として扱われます。
進行中の作業を管理するために、「フィーチャーフラグ」を使い、準備が整うまでコードが有効にならないようにします。この単一ブランチのアプローチは、複数の開発の流れを並行して進められる長期間存続するブランチを複数持つGitFlowなど、他の開発手法とは異なります。
CI/CDフレームワークにおけるCIの重要性
CIを活用すると、複数の開発の流れを慎重にすり合わせる必要がある、従来の「マージデー」の問題を回避できます。このすり合わせは複雑でエラーが起こりやすく、コード変更のリリースそのものへの信頼を損なうおそれがあります。また、自動化されたCIパイプラインがあれば、単体テストや統合テストを定期的に実施するなど、他の優れたプラクティスの促進にもつながります。技術的には、CIでは開発者が作業中のコードを頻繁に1つのブランチにチェックインする必要があります（つまり、機能開発のためにブランチを作成しません）。ただし、一般的な運用では必ずしもこれが守られているとは限りません。
継続的デリバリー（CD）とは？
継続的インテグレーションでは、開発中の変更を定期的にメインのコードラインへ統合します。継続的デリバリーでは、コードをデプロイ可能な単位にパッケージ化します。DevOpsモデルでは開発者自身がデプロイでき、必要に応じて別の運用チームが担当することもできます。これは、本番環境への変更を自動的にデプロイするプロセスを指す「継続的デプロイメント」と混同されることがよくあります。実際には、技術的な定義よりも後者の意味で使われることが多くあります。
継続的デプロイメントとは？
継続的デプロイメントを導入すると、手動での作業をなくし、アプリケーションを自動的にリリースできます。このアプローチでは、DevOpsチームが事前にリリース基準を定義し、その基準が満たされて検証されると、コードがそのまま本番環境にプッシュされます。これにより、組織は変化に迅速に対応し、新機能をより早くユーザーに届けられます。
継続的デリバリー（CD）や継続的デプロイメントを導入せずに継続的インテグレーション（CI）を実践することは可能ですが、CDにはCIが欠かせません。コードを共有リポジトリに統合する、テストとビルドを自動化する、毎日小さな単位で頻繁に作業するといったCIの基本がなければ、必要に応じて本番環境にデプロイすることはほぼ不可能です。
CI/CDパイプラインとは？
CIとCDのプラクティスでは、同じ作業を定期的に繰り返す必要があるため、自動化が最適です。CIとCDのプロセスの自動化は、従来の工場における製品の自動化ラインになぞらえて、一般に「パイプライン」と呼ばれます。DevOpsの重要な原則は自動化（DevOpsのCALMSモデルの「A」）であるため、CI/CDパイプラインはDevOpsのプラクティスに欠かせないものと考えられています。単一のチームが本番環境までのパイプラインを構築・保守する（より純粋なDevOpsモデル）ことも、CI/CDパイプラインで安定性とテスト品質を高めたビルド成果物を作成し、別の運用チームにデプロイを任せることもできます。
CI/CDインテグレーションのメリット
CI/CDパイプラインを活用すると、信頼性を高めるための変更も導入しやすくなります。たとえば、ビルドやデプロイのサイクルの早い段階で、単体テストや統合テストを簡単に組み込めます。これは「シフトレフト」と呼ばれ、デリバリープロセスの早い段階で問題を発見できるため、大幅なコスト削減につながる可能性があります。
同様に、パイプラインは変更を「少しずつ、頻繁に」リリースする環境を促進します。小規模な変更はそれぞれシステム全体へのリスクが小さいため、リスクの軽減にもつながります。一方、従来の「ビッグバン」方式では、多くの変更をまとめて、大規模かつ不定期にリリースします。
最後に、手動での作業を減らすことで、リスクをさらに軽減できます。機械は人よりも安定しているためです。自動化されたパイプラインがビルド中に誤ったコマンドを実行したり、リリースサイクルでQAテストを忘れたりする心配はほとんどありません。
近年のGitOpsの普及は、パイプラインのコードを基盤としており、パイプライン全体をソース管理に置くことを重視します。さらに、自動化された制御エージェントがデプロイ状態を管理し、ソースと一致するように保ちます。
CI/CDパイプラインとセキュリティ
ソフトウェアセキュリティ管理において、CI/CDパイプラインの普及は新たな機会をもたらす一方、新たな脅威も生み出しています。メリットとして、CI/CDパイプラインはビルドやデプロイのプロセスへの無制限なアクセスを制限できます。また、ユーザー（「実際の」ユーザーとサービスの両方）に管理者権限をすべて付与するのではなく、必要なリソースだけに対するきめ細かなアクセス権を付与しやすくなります。パイプラインはビルドとデリバリーの監査可能性も大幅に高めます。各ステップで、実行されたアクション、その結果、そして実行のきっかけ（または実行者）を簡単に記録できるためです。
前述のとおり、CI/CDのデメリットは脅威が増えることです。2000年以降、さまざまな要因によってコードの量だけでなく、ソースやソフトウェアプラットフォームの数も急増しました。開発とデプロイが加速し、パイプラインの信頼性が高まるにつれて、ソフトウェアはかつてない速さでデプロイされるようになっています。
オープンソースソフトウェアライブラリやプラットフォーム、ツールの普及により、開発者が利用できるソフトウェアの選択肢も大幅に増えました。さらに、柔軟なパッケージングおよびデプロイ技術としてのコンテナ化や、RESTインターフェースおよびgRPCを介したソフトウェアコンポーネントの相互運用性により、こうしたコンポーネントをこれまで以上に簡単かつ迅速に一緒に構築・デプロイできるようになりました。
こうした要因が重なり、中央の部門だけでは管理しきれないほど大量の新しいソフトウェアが生まれました。セキュリティ、運用、アーキテクチャの各チームは、この絶えず変化する新しい環境に適応する必要に迫られています。
こうしたプレッシャーを背景に、開発、デプロイ、保守における責任共有というDevOpsモデルを拡張し、セキュリティを密接に統合するDevSecOpsが生まれました。
CI/CDパイプラインツール
CI/CDパイプラインは、単純なシェルスクリプトと、AntやMavenなどのMakeファイルの派生ツールを組み合わせたものとして始まりました。やがて、この機能を担う、より本格的なアプリケーションが広く使われるようになりました。こうしたアプリケーションの中には、シンプルなサーバーサイドアプリケーションとして始まり、その後、独立した商用製品として成功したものもあります。この分野の主要な製品はJenkinsとTeamCityです。これらのツールでは当初、アプリケーションのGUIを通じて、サーバー側に状態を保持する形でパイプラインの設定を保存していました。しかし近年では、リモートのソースリポジトリから取得する、宣言型の「コードとしてのパイプライン」が主流になっています。
たとえばSnykを活用すれば、静的アプリケーションセキュリティテストなどにより、依存関係に含まれる既知の脆弱性を継続的に回避できます。Snykのセキュリティインテグレーションは、TeamCity、Jenkinsをはじめ、さまざまなCI/CDツールやシステムで利用できます。GitHubリポジトリでは、Snykのインテグレーション設定例をご確認いただけます。
主要なソース管理サービスもCI/CDに対応しています。GitLabはGitLab CI/CDをいち早く提供し、続いてGitHubがGitHub Actionsをリリースしました。SnykはGitLabとGitHubの両方と連携できます。
もちろん、主要なクラウドプロバイダーもこうしたサービスを提供しています。AzureにはPipelinesがあり、AWSはCodePipelineを提供しています。AzureとAWSのどちらの製品もSnykと連携できます。
業界標準となったCI/CD
1991年にCIという言葉が生まれて以来、CI/CDはニッチなプラクティスから業界標準へと変化しました。さらに、オープンソースの普及、コンテナ化、分散アプリケーションが相互に作用し、見渡す限り多様なツールやテクノロジーにまたがるソフトウェア成果物が爆発的に増加しました。
しかし、こうした状況は、すべての新たな攻撃対象領域を管理しようとするソフトウェアデリバリーパイプラインの管理者にとって、セキュリティ上の問題となっています。一方で、手動の検証は持続可能でも効率的でもなく、信頼性にも欠けます。パイプラインに追加できるさまざまなセキュリティ監査の種類はこちらでご確認ください。
開発プロセス全体を通じて、開発者のセキュリティを強化しましょう。パイプラインの自動化をSnykの脆弱性スキャンと連携できます。Snykのすべてのインテグレーションはこちらをご覧ください。
CI/CDパイプラインにセキュリティを組み込む
Snykはお使いのCI/CDパイプラインで動作し、優先度の高い脆弱性の修正を支援します。