ポイント: 継続的インテグレーション (CI)、継続的デリバリー (CD)、および継続的デプロイメントは、ソフトウェア開発の効率を向上させるための重要なDevOpsプラクティスです。CIは頻繁なコード統合に焦点を当て、CDはリリースの準備を自動化し、継続的デプロイメントは更新を直接本番環境にプッシュし、デリバリープロセスを最適化します。
- CIはコード変更が自動テストを通じて検証されることを保証します。
- CDはリリースプロセスを自動化しますが、手動の承認が必要です。
- 継続的デプロイメントは、成功したビルドを手動のステップなしで自動的にデプロイします。
継続的インテグレーション (CI)、継続的デリバリー (CD)および継続的デプロイメントは、ソフトウェアが開発から本番環境に移動する方法を定義する三つの異なるが相互依存するDevOpsプラクティスです。CIは頻繁にコード変更をマージし検証することに重点を置いており、CDは自動リリース準備を追加し、継続的デプロイメントは本番環境へのプッシュを完全に自動化します。これらのプラクティスは一緒に、無駄を削減し、「インテグレーション地獄」を排除し、エンドユーザーへのデリバリーを加速します。
（この記事は、私たちのDevOpsガイドの一部です。）
なぜ従来のソフトウェア開発は問題を引き起こすのか？
従来の開発ワークフローでは、開発者は数週間または数ヶ月にわたり、別々のフィーチャーブランチで独立して作業し、その後それらを統合します。この遅延した統合は、新しいバグや未テストの競合を一貫して生み出し、QAチームはプレッシャーの中で問題を解決しなければならず、プロジェクトマネージャーは予期しない遅延を吸収しなければなりませんでした。
その結果、完全でないブランチを統合するために奮闘する開発者、不明な欠陥を消火するテスター、そしてスケジュールが遅れるリリースが生まれます。以前のBMCの投稿では、CI/CDの目的を詳細に説明しました。ここで取り上げるCI/CDプラクティスは、統合、テスト、およびデプロイメントを定期的ではなく継続的にすることで、これらの問題を解決するために設計されました。
出典：Testcollab
継続的インテグレーション (CI) とは？
継続的インテグレーションは、頻繁にコード変更を中央の共有リポジトリにマージし、各マージを自動化されたテストで検証する実践です。目標はフィーチャーブランチを完成させることではなく、すべての統合された変更が常にパッケージビルドとして一緒に機能することを確認し、問題がすぐに浮上し修正されることです。
継続的インテグレーションの主な特徴：
- 開発者はコードを書き、ユニットテストを実行し、共有リポジトリにパッケージをコミットします。
- コード変更は頻繁にマージされます - 毎日のように複数回マージされることもあります。
- CI段階の焦点はビルドの安定性であり、フィーチャーの完成ではありません。
- 自動化ツールが一貫したビルドおよびテスト環境を維持し、「私のマシンではうまくいった」問題を排除し、フィーチャーブランチ間のコラボレーションを促進します。
- ビルド品質に関するフィードバックが早期に浮上し、開発者に対する統合問題の即時の文脈を提供します。
- テストはフィーチャーブランチとメインラインブランチの両方のレベルで行われます。
継続的デリバリー (CD) とは？
継続的デリバリーは、CIに自動リリース機能を追加することで拡張されます。継続的インテグレーションに合格した各コードコミットは、本番環境を再現したステージング環境でさらなるパフォーマンスと機能のテストを受け、手動の承認ステップの後にいつでもリリースの準備が整います。
継続的デリバリーの特徴は、リリースの決定が人間のものであること、通常は技術的なものではなくビジネスの決定であることですが、リリースプロセス自体は自動化可能で、繰り返し可能で、単一のアクションで実行可能です。
継続的デリバリーの主な特徴：
- 強力な継続的インテグレーションは、効果的な継続的デリバリーの前提条件です。
- リリースパイプラインは短く、自動化され、繰り返し可能です。
- 自動テストとビルドが全体を通じて強調されます。
- 各フィーチャー候補は、承認されるとすぐにデプロイ可能です。
- エンドユーザーへのフィーチャーのリリースはビジネスの決定であり、技術的な制約ではありません。
継続的デプロイメントとは何か？
継続的デプロイメントは継続的デリバリーの次の進化であり、検証されたビルドが自動的に本番環境にプッシュされます - 手動の承認は必要ありません。失敗した自動テストのみが変更のライブ化を妨げます。
継続的デプロイメントモデルにおけるリリースは、通常は最初に少数のエンドユーザーを対象にされ、即座のフィードバックが開発者に返されて次の反復に役立ちます。このモデルでは、開発者、テスター、および運用チーム間の共有された文化とマインドセットが必要であり、全体のSDLCパイプラインを共同で所有し、すべての小さなコードコミットが迅速にデプロイ可能であることを保証しなければなりません。
継続的デプロイメントの主な特徴：
- 本番環境へのデプロイは完全に自動化されており、人間のゲートはありません。
- すべての自動テストが合格する必要があります。単一の失敗がリリースを停止します。
- メインラインブランチは継続的に本番ステージに進みます。
- リリースはリリースプロセスのペースで十分に文書化されています。
- 自動化テストは最大のコードカバレッジで採用されています。
- デプロイは小さく、頻繁なフィーチャー更新のバッチで行われます。
- エンドユーザーは、コードコミットの数分以内に継続的な変更を受け取ります。
- DevOpsチームとエンドユーザー間のフィードバックループの短縮は、運用負担を軽減します。
継続的デプロイメントは、コード変更を書いてからエンドユーザーがそれを体験するまでの時間を、数日または数週間から数分に圧縮します - すべての自動テストが合格する限り。
DevOpsチームはどのように適切なアプローチを選択すべきか？
継続的インテグレーション、継続的デリバリー、および継続的デプロイメントは定義された原則に従いますが、各組織はこれらのプラクティスを自分のチーム構成、ツール、およびビジネス要件に適応させます。すべてのチームが完全な継続的デプロイメントを必要とするわけではなく、適切なリリースのペースはリスク許容度、規制要件、製品の成熟度によって異なります。
すべてのDevOpsチームは、自身の特定の要件を評価し、これらの三つの相互依存するCI/CDプラクティス間のコアの違いに基づいたリリース戦略を設計する必要があります。
よくある質問
継続的デリバリーと継続的デプロイメントの主な違いは何ですか？
継続的デリバリーでは、ビルドはリリース準備が整っていますが、本番環境へのプッシュには人間の承認が必要です。継続的デプロイメントでは、その承認ステップが排除されます - すべての自動テストに合格したビルドは、本番環境に自動的にデプロイされます。
継続的デプロイメントには継続的インテグレーションが必要ですか？
はい。継続的デプロイメントは、継続的インテグレーションの強固な基盤に依存します。信頼できる自動化されたCIテストがなければ、ビルドが自動的に本番環境にデプロイするのに安全であるという信号はありません。
継続的デプロイメントパイプラインでリリースを停止するのは何ですか？
失敗した自動テストが継続的デプロイメントパイプラインの主要なゲートです。すべてのテストが合格すれば、ビルドは人間の関与なしに本番環境にデプロイされます。テストの失敗のみがプロセスを停止します。
CI/CDの文脈で「インテグレーション地獄」とは何ですか？
「インテグレーション地獄」とは、長期間独立したフィーチャーブランチを統合する際の痛みを伴うプロセスを指します。継続的インテグレーションは、開発者が頻繁に共有リポジトリにマージすることを要求することでこれを解決します - 多くの場合、1日に複数回マージされるため、競合は早期に浮上し、管理可能な状態を保ちます。
チームはCIを導入してCDを実装しなくてもよいですか？
はい。多くのチームは、ビルドの品質を向上させ、統合の問題を早期に発見するために最初に継続的インテグレーションを採用し、その後、自動化の成熟が進むにつれて継続的デリバリーや継続的デプロイメントを追加します。CIはCDの前提条件ですが、CDはCIプラクティスの恩恵を受けるためには必要ありません。
この記事に表現された意見や見解は著者のものであり、必ずしもBMCの公式な立場を反映するものではありません。
DevOpsガイド
- DevOpsとは？包括的な紹介
- DevOpsの簡単な歴史
- DevOpsアーキテクチャの紹介
- DevOpsにおける自動化：なぜDevOpsの実践を自動化する必要があるのか
- CI/CDとは？継続的インテグレーションと継続的デリバリーの説明
- Jenkinsを使用してCI/CDパイプラインを構築する方法
- CI/CDパイプラインを最適化するためのDevOpsメトリック
- 継続的デリバリーメトリック
- 継続的インテグレーションから継続的デプロイメントへの進展は進行中か - それともそうでないか？
- 継続的インテグレーション (CI)、デリバリー (CD)、およびデプロイメントの違い
- DevOpsにおけるソースおよびバージョン管理
- 継続的テストとは？
- テスト自動化フレームワーク：究極のガイド
- DevOpsにおけるリリース管理
- 解説：DevOpsにおける監視とテレメトリー
- DevOpsにおけるアプリケーションパフォーマンス管理
- SDLCにおけるDevOpsオーケストレーション
- データベースDevOpsの紹介
- DevOpsにおけるマイクロサービスの役割
- DevOpsにおける仮想化の役割
- コンテナとDevOps：コンテナがDevOpsデリバリーパイプラインにどのようにフィットするか
- コンテナパイプラインとは？
- DevOpsツールチェーンとは？
- DevOpsのためのコンテナとコードの管理
- DevOpsにおけるアジャイルの役割
- DevOpsにおけるクラウドの役割
- FinDevOpsとは？
- 2022年のトップDevOpsトレンド
- DevOpsの価値と原則
- DevOpsメトリックとKPI
- 小規模、中規模、大規模組織のためのDevOpsのアドバイス
- DevOpsチームの構造
- 今日読むべきトップDevOps本
- 『The Phoenix Project: DevOps For Everyone』の書評
- DevOpsインフルエンサー：Twitterでフォローすべき11人のDevOps専門家
- GitHub、GitLab、BitbucketおよびAzure DevOps：違いは何か？
- ベストプラクティス：Kubernetes用にアプリケーションをアーキテクチャ設計する方法
- DevOpsにおける構成管理
- DevOpsのブランチ戦略の説明
- DevOpsの職務名、役割、責任
- DevOpsにおけるテスト：概念、ベストプラクティスなど
- 2022年の完全なDevOps認定ガイド
- Kubernetesオペレーターパターンとは？
これらの投稿は私自身の意見であり、必ずしもBMCの立場、戦略、または意見を代表するものではありません。