継続的統合/継続的デリバリー（CI/CD）とは

CI/CDパイプラインの重要な特徴の一つは、コードの品質を確保するためのオートメーションの活用です。ソフトウェアの変更がパイプラインを通過するにつれて、自動テストは依存関係やその他の問題を早期に特定し、コード変更を別の環境にプッシュし、アプリケーションを本番環境に配信します。

ここでオートメーションが果たす役割は、品質管理を実行することであり、性能からアプリケーション・プログラミング・インターフェース（API）の使用状況やセキュリティに至るまで、あらゆるものを評価します。このプロセスにより、すべてのチーム・メンバーが行った変更が包括的に統合され、意図したとおりに実行されるようになります。

CI/CDパイプラインのさまざまなフェーズを自動化する機能により、開発チームは品質を向上させ、作業を迅速化し、その他のDevOpsメトリクスを改善することができます。

CI/CDパイプラインはアジャイルDevOpsワークフローを指しますが、CI/CDは継続的統合と継続的デリバリーを組み合わせた手法を表します。

CI/CDは、さまざまな人々の作業を1つの一貫性のある製品に組み合わせるための、より迅速かつ正確な方法を生み出します。DevOps環境では、CI/CDはアプリケーションのコーディング、テスト、デプロイメントのプロセスを合理化します。このアプローチにより、チームは作業を保管するための単一リポジトリと、コードを組み合わせてテストし、一貫して機能することを確認するためのオートメーションを利用できるようになります。

CI/CDパイプラインを使用すると、DevOpsチームはコードの記述、統合、テストの実行、リリースの提供、ソフトウェアへの変更のデプロイをリアルタイムで共同で行うことができます。初期テストから最終的なデプロイメントまで、ソフトウェア・リリースの自動化は、CI/CDパイプラインの大きなメリットですが、その他のメリットには次のようなものがあります。

• デプロイメント時間の短縮：テストを自動化すると、開発プロセスがより効率的になり、ソフトウェア配信プロセスのデプロイメント時間が短縮されます。さらに、継続的デプロイメント や自動 プロビジョニング により、開発者がクラウドアプリケーションに変更を加えた変更を書いてから数分で実現できます。

• コスト削減:開発、テスト、生産を迅速に行える (自動化により促進) ため、開発に費やす時間が短縮されます。このプロセスは、従来のソフトウェア開発に比べてコストが削減される成果になります。

• 継続的なフィードバックループ： CI/CDパイプラインは、ビルド、テスト、デプロイという継続的なサイクルを表します。フィードバック・ループにより、開発者はテスト後に迅速に行動し、コードをテストするたびにコードを改善できます。

• 早期エラー検知：継続的統合では、統合における問題を検出するために、ビルドされたコードの各バージョンに対してテストが自動化されます。これらの問題は、パイプラインで発生する早期に発生するほど、修正プログラムが容易になります。

• ダウンタイムの削減と信頼性の向上：デプロイメントの失敗、バグ、または性能の問題が発生した場合、自動ロールバックなどの主要な機能により、ソフトウェアシステムまたはアプリを以前の安定した状態に戻すことができます。主要な機能はダウンタイムを最小限に抑え、サービス信頼性を高めます。

• チームコラボレーションとシステム統合の向上：チームの全員がコードを変更し、フィードバックに対応し、問題に迅速に対応できます。

CI/CDパイプラインは、以下の3つの関連するメソッドで構成されています。

• 継続的統合
• 継続的デリバリー
• 継続的デプロイメント

CI/CDプロセスは継続的統合(CI)から始まり、開発者はバージョン管理システム(VCS)が管理する中央リポジトリにコードをコミットします。CIにより、開発者は独立して作業し、独自のコーディング「ブランチ」を作成して、小さな変更を実装できます。

開発者は作業を進めながら、通常はGitなどのバージョン管理ツール内でソースコードのスナップショットを撮ることができます。その後、開発者は自由に主要な機能の開発に取り組むことができます。問題が発生した場合、Gitはコードベースをすぐに以前の状態に戻すことができます。

個人の作業は、スクリプトを使用してコード変更をビルドおよびテストする自動システムにプッシュされます。自動化されたビルド段階の後、CIサーバーはソースコードの変更を共有ソースコード・リポジトリーのメイン・ブランチ・コード、つまり「トランク」にコンパイルします。

CI/CD 開発プロセスでは、コードを独自に作成してメインのコードブランチに毎月1回送信すると、バグ修正やバージョン管理の不備に負担がかかる可能性があります。しかし、CI/CD 開発プロセスでは、チームがコード変更をより頻繁に提出できるようになります。この継続的なテストはバグの修正プログラムを迅速に行い、機能性を確保し、最終的にはより良いコラボレーションとソフトウェア品質の向上につながります。

パイプラインの次のステップは継続的デリバリー（CD）であり、統合で行われた検証済みのコード変更を、GitHubなどの特定の環境またはコードリポジトリに配置します。ここで、オペレーションチームはそれらを実際の運用環境にデプロイできます。

ソフトウェアとAPIはテストされ、エラーは自動化されたプロセスによって解決されます。CDプロセスの最後のステップで、DevOpsチームは最新のビルドに関する通知を受け取り、それを手動でデプロイメントステージに送信します。

継続的Delivery Pipeline段階の目標は、最小限の労力で新しいコードをデプロイすると同時に、ある程度の人間による監視を可能にすることです。

CI/CDプロセスにおけるCDは、継続的デプロイメントの略でもあります。継続的デプロイメントでは、コピーテキスト環境でコードをテストする統合テストなど、事前定義された一連のテストに合格した後、コード変更をエンド・ユーザーに自動的にリリースして、コードの整合性を確保します。

継続的デリバリーと継続的デプロイメントはどちらも、CIよりもパイプラインの下流でのオートメーションを扱い、多くの場合同じ意味で使用されます。

継続的デリバリーと継続的デプロイメントの違いは、ソフトウェアまたはアプリのリリースに用いられる自動化の程度にあります。継続的デリバリーでは、リスクの評価やソースコードに潜む脆弱性の特定など、さらなるテストと品質保証を行うために、コードは自動的に疑似本番環境へ移されます。テストが成功した後に本番環境へ移行するには人間の介入が必要です。

継続的デプロイメントではさらなる自動化が行われます。コードがテストに合格すると、自動的に本番環境へのデプロイメントが行われ、人間による承認は不要です。

組織がCI/CDパイプラインをどのように適用し、継続的デリバリーとデプロイメントを利用するかは、ビジネス・ニーズによって異なります。継続的デプロイメントは、eコマースサイトやSaaS（Software as a Service）プラットフォームを構築するような、開発ライフサイクルが速いDevOpsチームに最適です。

継続的デプロイメントは、チームが新しいソフトウェアや更新されたソフトウェアを頻繁かつできるだけ早くリリースできるようにすることで、ソフトウェアのリリース・プロセスをサポートします。変更は自動的に一般にデプロイされるため、このタイプの継続的デプロイメント・パイプラインは通常、実証済みのプロセスを持つDevOpsチームのみが使用します。

ワークフローにおいてそれほど頻繁に更新プログラムをリリースする必要がないチーム（医療アプリケーションを構築しているチームなど）の場合、継続的デリバリーが通常、望ましい選択肢となります。処理速度は遅くなるものの、エンドユーザーにとっての機能性を確保するための監視体制がさらに強化される。

継続的デリバリーと継続的デプロイメントの違いについて詳しくは、こちらのビデオをご覧ください。

機械学習パイプラインは、機械学習モデルの組み込み、トレーニング、評価、導入プロセスを自動化、標準化、合理化するために設計された、相互接続された一連のデータ処理およびモデリングのステップです。

機械学習パイプラインは、機械学習（ML）システムの開発と運用において不可欠なコンポーネントである。さらに、ビッグデータや人工知能（AI）の発展に伴い、それらはますます重要になってきている。

キングス研究によると、世界の機械学習市場規模は2023年に260億6,000万米ドルと評価され、2024年の354.4億米ドルから2031年までに3,288.9億米ドルに成長し、予測期間中のCAGRは37.47％になると予測されています。¹

機械学習パイプラインはDevOpsプラクティスと統合され、機械学習モデルのCI/CD（継続的インテグレーション／継続的デリバリー）を可能にします。この統合は機械学習オペレーション（MLOps）と呼ばれ、データサイエンスチームがMLオーケストレーションの管理の複雑さを効果的に管理するのに役立ちます。

ソースコードから本番環境まで、これらの段階は CI/CD パイプラインの開発ライフサイクルとワークフローを構成します。

• 構築
• テスト
• 提供されるもの
• 展開

この段階は継続的統合プロセスの一部であり、コードの作成とコンパイルが含まれます。チームは協力してソースコードを構築し、問題やコンフリクトを迅速に特定しながら新しいコードを統合します。

この段階では、チームはコードをテストします。自動テストは、継続的デリバリーとデプロイメントの両方で行われます。これらのテスト環境には、統合テスト、単体テスト、回帰テストが含まれる場合があります。

ここで、承認されたコードベースが本番環境に送られます。この段階は継続的デプロイメントでは自動化され、開発者の承認後にのみ継続的デリバリーで自動化されます。

最後に、変更がデプロイされ、最終製品が本番環境に移行します。継続的デリバリーでは、製品またはコードがリポジトリーに送信され、人間の承認によって本番環境またはデプロイメントに移行します。継続的デプロイメントでは、このステップは自動化されます。

CI/CDツールを選択する際には、ソフトウェア開発プロセスの最適化と自動化に重点を置く必要があります。効果的なCI/CDパイプラインは、統合、テスト、デプロイメントにオープンソースツールを使用します。CI/CDプロセスの正しい構成は、ソフトウェア開発パイプラインの成功にも影響を与えます。

最も一般的なオープンソースのCI/CDツールはJenkinsです。JenkinsはJavaで記述された自動化されたCIサーバーであり、CI/CDの手順とレポート作成を自動化するために使用されます。統合用のその他のオープンソース・ツールには、Travis CIやCircleCIなどがあります。

オープンソース・ツールに加えて、すべての主要なクラウド・サービス・プロバイダー（Google Cloud、IBM Cloud、Microsoft Azure、Amazon Web Services（AWS））は、クラウド・ベースのCI/CDツールチェーン、パイプライン、およびツール統合を提供しています。

GitHubやAWS CodeCommitなどの統合開発環境（IDE）は、開発者がソフトウェア・パッケージを作成、保守、追跡するのに役立ちます。同時に、GitLabなどのプラットフォームは、他のツールを含む包括的なプラットフォーム内でIDEを提供することを目指しています。

クラウド環境で運用する場合、クラウドネイティブなDevOpsチームは、アプリケーションのパッケージングと出荷にDockerなどのコンテナを使用し、Kubernetesなどのコンテナオーケストレーションツールを使用します。Kubernetesは厳密にはCI/CDパイプライン向けではありませんが、多くのCI/CDワークフローで使用されています。

CI/CDセキュリティーは、CI/CDパイプライン全体でセキュリティーおよびコンプライアンス対策を実装および管理する実践、プロセス、テクノロジーに重点を置いています。

これまで、セキュリティは開発サイクルの最後にソフトウェアに「付加」されていました。クラウド・プラットフォーム、マイクロサービス、コンテナの進歩により、従来の開発アプローチにボトルネックが生じました。

開発者がアジャイルとDevOpsのプラクティスを採用し、開発、セキュリティ、オペレーションの略であるDevSecOpsの進化に拍車をかけたため、セキュリティは迅速なリリースに追いついていない可能性があります。DevSecOpsは、継続的インテグレーション（CI）および継続的デリバリー（CD）パイプライン内で表示されるセキュリティー・ツール・プラクティスの統合を自動化します。

DevSecOpsプラクティスには、シフト・レフトテストとシフト・ライトテストが含まれていました。シフト・レフトテストとは、セキュリティテストやその他のクリティカルな開発手法を、ソフトウェア開発ライフサイクル（SDLC）のより早い段階で統合することを指します。シフトライト・テストでは、開発の後半に、通常は本番環境でテストを行います。これらの方法は、テストの責任を SDLC 全体に分散することで相互に補完し合います。