CI/CD とは

CI/CD (継続的インテグレーションおよび継続的デリバリー/デプロイメントの略) は、ソフトウェア開発ライフサイクルを最適化し、加速することを目的としています。

継続的インテグレーション (CI) とは、コード変更を共有ソースコードリポジトリに自動的かつ頻繁に取り込む手法のことです。継続的デリバリーまたはデプロイメント (CD) は 2 つの部分からなるプロセスで、コード変更の統合、テスト、デリバリーを指します。継続的デリバリーは、本番環境への自動デプロイは行わずその手前までを守備範囲としますが、継続的デプロイメントは、更新内容を本番環境に自動的にリリースします。

これらの連結した作業習慣はまとめて「CI/CD パイプライン」と呼ばれ、DevOps または SRE (サイト信頼性エンジニアリング) のいずれかのアプローチを使用してアジャイルな方法で共同作業する開発チームと運用チームが実施します。

CI/CD は、ソフトウェア開発および更新の継続的なサイクルを維持しながら、バグやコードの不具合を回避するのに役立ちます。

アプリケーションが増大する中、CI/CD の機能は複雑さを軽減し、効率を高め、ワークフローを最適化するための助けとなります。

CI/CD は、新しいコードをコミットから本番環境に取り込むために従来必要とされていた手作業よる介入を自動化するので、ダウンタイムが最小限に抑えられ、コードのリリースが迅速化されます。また、コードの更新や変更をより迅速に統合できるため、ユーザーのフィードバックをより頻繁かつ効果的に組み込むことができ、ユーザーにとってプラスの結果が生み出され、顧客の満足度が全体的に向上します。 

CI/CD の「CI」は常に継続的インテグレーションを指します。これは、コード変更をより頻繁にマージして共有ブランチ、つまり「トランク」に戻す作業を容易にする開発者向けの自動化プロセスです。この更新が行われると、マージされたコード変更の信頼性を確保するため、自動テストの手順がトリガーされます。

現代のアプリケーション開発では、複数の開発者が同じアプリケーションの別の機能に対して同時に作業することが目標です。ただし、すべてのソースコードのブランチを 1 日 (いわゆる「マージ日」) でマージするよう計画しているのなら、その作業は膨大になり、自動化されず、時間がかかります。

これは、単独で作業している開発者がアプリケーションに変更を加えると、他の開発者が同時に行っているさまざまな変更と競合する可能性があるためです。チーム全員が 1 つのクラウドベース統合開発環境 (IDE) を使うのではなく、開発者それぞれがローカルで IDE をカスタマイズして使用している場合、この問題はさらに大きくなります。

CI は、同時に生じる開発中のアプリケーションのブランチが多すぎて、互いに競合する可能性があるという問題の解決策と考えることができます。

適切に機能する CI では、開発者によるアプリケーションへの変更がマージされると、その変更によりアプリケーションが自動的に構築され、さまざまなレベルの自動テスト (通常はユニットテストと統合テスト) を実行して検証され、変更によりアプリケーションが破損していないことが確認されます。この検証では、クラスや関数から、アプリケーション全体を構成するさまざまなモジュールに至るまで、あらゆるものがテストされます。自動テストによって新しいコードと既存のコードの競合が発見された場合、CI を使用することで、そのようなバグの迅速かつ頻繁な修正が容易になります。

CI/CD の「CD」は継続的デリバリーまたは継続的デプロイメントを指します。これらは関連性のあるコンセプトで、時には同じ意味で使用されることもあります。どちらもパイプラインのさらなる段階の自動化に関するものですが、自動化の程度を示すために切り離して使用されることもあります。継続的デリバリーと継続的デプロイメントのどちらを選択するかは、リスク許容度と、開発チームと運用チームの具体的なニーズによって異なります。

継続的デリバリーでは、CI でのビルドおよびユニットテストと統合テストの自動化に続いて、検証済みコードのリポジトリへのリリースが自動化されます。したがって、効果的な継続的デリバリーのプロセスを実現するには、CI がすでに開発パイプラインに組み込まれていることが重要です。

継続的デリバリーでは、コード変更のマージから本番環境に対応したビルドのデリバリーに至るまで、あらゆる段階でテストの自動化とコードリリースの自動化が行われます。運用チームはこのプロセスの最後に、アプリケーションを本番環境に速やかにデプロイすることができます。

継続的デリバリーは一般に、開発者によるアプリケーションへの変更に対して、バグがないか自動的にテストし、リポジトリ (GitHub やコンテナレジストリなど) にアップロードします。ここで、変更が運用チームによって本番環境に導入されます。これは、開発チームとビジネスチームの間の可視性とコミュニケーションが不十分である場合、その解決策となります。継続的デリバリーの目的は、本番環境にいつでもデプロイできるコードベースを用意し、新しいコードのデプロイにかかる労力を最小限に抑えることです。

成熟した CI/CD パイプラインの最終段階は、継続的デプロイメントです。継続的デプロイメントは継続的デリバリーを拡張したものであり、リポジトリから本番環境への開発者による変更のリリースを自動化し、顧客が使用できるようにするというものです。

CD は、手動プロセスによって運用チームに過負荷がかかり、アプリケーション提供に遅れが生じるという問題に対処します。継続的デリバリーのメリットを活用し、パイプラインの次のステージを自動化します。

実際には、継続的デプロイメントによって、開発者によるクラウドアプリケーションへの変更は、作成してから数分以内に実稼働できます (自動テストに合格した場合)。これにより、ユーザーからのフィードバックを継続的に受け取り、反映することが簡単になります。これらすべての CI/CD 手法が連結することで、アプリケーションのデプロイメントのリスクが軽減され、アプリケーションへの変更を一度にリリースするのではなく、少しずつリリースすることが容易になります。

しかし、実稼働以前のパイプラインの段階では手動ゲートがないため、継続的デプロイメントは適切に設計されたテスト自動化に大きく依存します。つまり、CI/CD パイプラインのさまざまなテストやリリースの段階に対応する自動テストを作成する必要があるため、継続的デプロイメントには多額の先行投資が必要になる可能性があります。

CI/CD は、開発チームと運用チームのコラボレーションの促進を目的とした DevOps 手法の重要な要素です。CI/CD と DevOps はどちらもコード統合プロセスの自動化に焦点を当てており、アイデア (新機能、拡張リクエスト、バグ修正など) を開発から本番へと進め、実際にユーザーに価値提供できるようにするまでのプロセスを迅速化します。

しかし、コラボレーションを重視する DevOps のフレームワークにおいては、セキュリティは最初から最後まで組み込まれ、その責任も共有されます。これは極めて重要な考え方なので、一部の人々からは「DevSecOps」という用語が作り出され、セキュリティ基盤を DevOps の取り組みに導入する必要性を強調しています。DevSecOps (開発、セキュリティ、運用) は、文化、自動化、およびプラットフォーム設計へのアプローチであり、IT ライフサイクル全体を通じてセキュリティを共有責任として統合します。セキュアな CI/CD パイプラインの導入は、DevSecOps の重要な要素です。

CI/CD セキュリティは、自動化されたチェックとテストによってコードパイプラインを保護し、ソフトウェア提供における脆弱性を防ぐために使用されています。シフトレフトとシフトライトなどのセキュリティ対策として、パイプラインにセキュリティを組み込むことで、コードを攻撃から守り、データ漏えいを防ぎ、ポリシーに準拠し、品質を保証することができます。

適切なセキュリティがないまま開発とデプロイメントが急速に進められると、パイプラインが次のようなリスクにさらされることがあります。

• 機密データの外部への流出
• 安全でないコードやサードパーティ製コンポーネントの使用
• ソースコードリポジトリやビルドツールへの不正アクセス

ソフトウェア開発サイクル全体を通じて脆弱性が特定、緩和されることで、コードの変更が本番環境にデプロイされる前に徹底的にテストされ、セキュリティ標準に準拠していることが確認できます。

CI/CD ツールは、開発、デプロイ、テストを自動化するために役立ちます。ツールには、特にインテグレーション (CI) 側を処理するものや、開発とデプロイ (CD) を管理するもの、継続的なテストや関連機能に特化したものがあります。

Tekton Pipelines は、コンテナによって標準のクラウドネイティブな CI/CD エクスペリエンスを提供する Kubernetes プラットフォーム向けの CI/CD フレームワークです。

Tekton Pipelines 以外にも、知っておくべきオープンソースの CI/CD ツールには次のようなものがあります。

• Jenkins：単純な CI サーバーから完全な CD ハブまであらゆるものを処理できるように設計されている
• Spinnaker：マルチクラウド環境向けに構築された CD プラットフォーム
• GoCD：モデリングと可視化に重点を置いた CI/CD サーバー
• Concourse：「オープンソースの継続的〇〇向けツール」
• Screwdriver：CD 用に設計されたビルド・プラットフォーム

さまざまなベンダーから入手できるマネージド型の CI/CD ツールを検討することが必要な場合もあります。主要なパブリッククラウドプロバイダーはすべて、GitLab、CircleCI、Travis CI、Atlassian Bamboo などとともに、CI/CD ソリューションを提供しています。

さらに、DevOps の基盤となるツールが CI/CD プロセスに使用されることがあります。構成の自動化 (Ansible、Chef、Puppet など)、コンテナランタイム (Docker、rkt、cri-o など)、コンテナ・オーケストレーション (Kubernetes) のためのツールは、厳密には CI/CD ツールではありませんが、 多くの CI/CD ワークフローで使用されます。

優先するアプリケーション開発戦略とクラウドプロバイダーに基づいて、CI/CDを実装する方法はさまざまです。Red Hat® OpenShift® Service on AWS には、Tekton や OpenShift Pipelines など、独自の CI/CD ワークフローをより容易にするためのオプションがいくつか用意されています。Red Hat OpenShift を使用することで、組織は CI/CD を採用して、複数のオンプレミスおよびクラウドプラットフォームにわたるアプリケーションの構築、テスト、デプロイを自動化できます。 

Red Hat のエキスパートは、組織が既存のアプリケーションをより効率的にモダナイズし、クラウドネイティブ・アプリケーション開発のプロセスを加速するために必要なプラクティス、ツール、文化を生み出すお手伝いをします。

Red Hat® OpenShift® は開発者の生産性の向上、CI/CD パイプラインの自動化、早期かつ開発サイクル全体を通じたセキュリティへの取り組みの移行を支援します。

Red Hat OpenShift Pipelines は、CI/CD パイプラインの各ステップを独自のコンテナで実行するように設計されており、パイプラインの要求に応じて各ステップを個別にスケーリングすることができます。つまり、管理者と開発者は、組織固有のビジネス要件とセキュリティ要件に基づいてアプリケーションのパイプラインのブループリントを作成できます。

Red Hat OpenShift GitOps は、git リポジトリ、継続的インテグレーション/継続的デリバリー (CI/CD) ツール、Kubernetes を統合するワークフローを提供し、品質を損なうことなく、より高速で安全かつスケーラブルなソフトウェア開発を実現する Operator です。OpenShift GitOps を使用すると、宣言型の Git 駆動型 CD ワークフローを構築して、アプリケーション開発プラットフォームに直接統合できます。

Red Hat Ansible® Automation Platform には、イベント駆動型ソリューション、分析、事前構築済みのコンテンツコレクションなど、組織全体での自動化の導入に必要なツールがすべて揃っています。YAML ベースの共通言語と望ましい状態をベースとするアプローチを使用することで、日常のオペレーションだけでなく、CI/CD パイプラインにも同じ自動化コンテンツを使用できます。また、IT インフラストラクチャのほぼすべての側面と連携できるため、一貫した開発環境、テスト環境、本番環境をより簡単かつ迅速に展開でき、アプリケーションの信頼性と回復力を高めることができます。

Ansible Automation Platform は Red Hat Advanced Cluster Management for Kubernetes とも統合するため、CI/CD パイプライン内で Kubernetes クラスタのオーケストレーションを行うことができます。また、人が理解しやすい自動化言語を使用して、Red Hat OpenShift Operator をより簡単に構築し、保守することができます。