継続的インテグレーション、デリバリー、デプロイメントの違い

CI と CD の主な特徴とそれらの違いについて見てみましょう。

継続的インテグレーション（CI）

継続的インテグレーション（CI）はコードの変更を自動的にチェックし、成果物に対するフィードバックを迅速に受け取る手法です。 CI では変更がコミットされるたびに CI サーバーがビルドを実行し、自動テストを実行します。 このようなテストには通常、ユニットテスト、統合テスト、およびリントや静的解析などのその他のチェックが含まれています。 CI プロセスのいずれかのステージが失敗すると、問題に対応できるように自動的にフィードバックが届きます。 このプロセスは修正がコミットされると再び最初から開始されます。

継続的デリバリーと継続的デプロイの比較

継続的デリバリーと継続的デプロイの違いは、最終ステージである本番環境へのリリースにあります。

継続的デリバリーの場合、本番環境にビルドアーティファクトをリリースするには手動操作が必要です。 リリースプロセスは完全に自動化されているのが通例ですが、特定のビルドのリリース可否とそのタイミングは誰かが決めなければなりません。 これとは対照的に、継続的デプロイの場合はこのプロセスに先行するステージが完了するたびにビルドが本番環境へ自動的にリリースされます。

継続的デリバリーと継続的デプロイの選択判断

継続的デリバリーと継続的デプロイのどちらが適しているかどうかは、状況に応じて判断されます。

モバイルアプリや API などのソフトウェア製品の場合、問題のないすべてのコミットごとに新しいバージョンをリリースするのは好ましくない場合があります。 そうではなく、スケジュールに沿ってリリースするか、デプロイ可能な変更が最低件数に達するまで待つのが良い場合があります。

このような場合は継続的デリバリーを使用することで、変更を加えながらそれを検証し、本番前の環境でリリースをプレビューすることができます。 継続的デリバリーでは各リリースの前に手動で受け入れテストを行う機会も得られます。

これに対し、継続的デプロイは毎日または毎時間の更新が通例であるウェブベースのアプリやサービスに適しています。

継続的デプロイでは小さな更新を段階的に行うことで、タイムリーなフィードバックを受け取ることができます。 継続的デプロイでは実際のユーザーを対象に実験を行って仮説を検証することも可能性であるため、必要に応じて新しいリリースを使用して素早く方向性を変えることができます。

最後になりますが、手動の受け入れテストと探索テストを継続的デプロイプロセスに組み込めることを覚えておいてください。

各リリースの前に手動チェックを要求する代わりに、ステージング環境に定期的に変更をデプロイし、毎週（またはそれ以上）の周期でこれらのテストを実行できます。

一方、すべての自動チェックに合格した変更はそのまま続けて本番環境にリリースできます。 ステージングで問題が見つかった場合は自動パイプラインによって本番環境に修正を素早くデプロイできます。

CI/CD はソフトウェアのビルド、テスト、およびリリースのプロセス内の 2 つのステージともいえるものです。

CI/CD パイプラインはコードへの自信を徐々に高めてくれるツールです。

ステージを通過するたびに自信がつき、コードをユーザーに安心してリリースできるようになります。 ただし、いずれかのステージに失敗した場合はビルドプロセスを停止し、バグを修正するか、変更を元に戻す必要があります。 問題が解決した後はプロセスが再び最初から開始されます。

CI はビルド、テスト、およびリリースプロセスの最初のフェーズであり、チェックを通した迅速なフィードバックに焦点を当てています。 コードの変更に対する迅速なフィードバックを得られるため、コンテキストスイッチングの必要性が少なくなり、作業の効率が向上します。 数時間や数日間も手動テストの結果を待つことなく、変更によって導入された問題に関する通知が数分で届きます。

変更を含むビルドが CI テストに合格すると、本番前環境へのデプロイが保証されます。 この時点で比較的時間のかかるテストやリソース消費の多いテストを実行できるようになります。

できる限り多くの CD ステップを自動化することで、フィードバックループを短縮し、ワークフローの効率を上げることができます。 テストの自動化に加えて、本番前環境を自動的にリフレッシュしてビルドをデプロイするといったことも可能です。

CI/CD を初めて取り入れる場合は、継続的インテグレーションと継続的デリバリーまたはデプロイの選択に重点を置くのではなく、何から始めてどこまで進めるのかを決めることをお勧めします。

CI と CD のどちらも複数のステップが伴うため、プロセスを徐々に構築するとよいでしょう。

出発点の発見

ビルドまたはリリースプロセスの一部をすでに自動化している場合、または自動テストを作成済みである場合は、そこから自然な出発点を得られます。 そうでない場合は、ビルド、テスト、およびリリースプロセスのどの部分に最も時間がかかっているのか、またはテストが不十分であることが原因で本番環境で問題が起きやすくなっていないかを考えることから始めてください。

多くのチームは組織内の他部署との調整があまり必要なく、自動ユニットテストと統合テストからの迅速なフィードバックを利用してコード品質を改善できる CI から始めることを選択します。

また、CI のメリットを認識することで自動テストの文化を育みやすくなります。これは CI/CD の効果を上げるのに不可欠であり、自動テストカバレッジのさらなる拡大を促進します。

一方、リリースの調整もコード開発も現在管理している場合は、CD の最終ステージ（本番環境へのリリース）を先に自動化することで長期的に時間を節約できます。

CI は CD の強力な基盤を提供しますが、継続的デリバリーと継続デプロイのどちらを選択するかは要件によって異なります。 長期的な目標が継続的デプロイであっても、継続的デリバリーから始めるのが一般的な方法です。 ワークフローに自信を持てるようになったら、本番環境への最終リリースを自動化する作業に進むことができます。

CI/CD プロセスの改善

CI と CD は開発タスクをより細かい成果物に分けて定期的に変更をコミットする場合に最適です。

継続的デプロイを目標とする場合は、変更がコミットされていてもまだリリースできる状態にない機能をどのように管理するかを検討する必要があります。 そのような管理は、フィーチャーフラグか進行中の作業をリリースブランチから切り離すブランチ戦略を使用し、自動的にビルドを行って各コード変更をテストすることで実現できます。

要約すると、以下のようになります。

• 継続的インテグレーション（CI）では変更がコミットされるたびに自動テストが実行され、ソリューションのビルドがチェックされます。
• 継続的デリバリーと継続的デプロイ（CD）ではテスト環境とステージング環境にビルドアーティファクトが自動的にデプロイされ、後続のテストが実行されます。 これらのステップは通常、継続的インテグレーションの後に実行します。
  • 継続的デリバリーでは、ユーザーが特定のビルドアーティファクトを本番環境にリリースするタイミングとリリースを手動で開始するタイミングを決定します。
  • 継続的デプロイでは、先行するステージを正常に通過したすべてのコードが自動的に本番環境にリリースされます。
• CI と CD は問題を迅速に特定し、変更をリリースする前に変更に自信を持てるようにすることを目的とした補完的な手法です。
• 自動テストを含む堅牢な CI/CD プロセスでは、バグが本番環境にリリースされた場合でもより迅速に自信をもって修正をデプロイできます。
• 完全に自動化されたビルド、テスト、およびリリースプロセスは CI でも CD でも構成されますが、どちらか片方のみで始めて段階的にプロセスを構築できます。
  • 多くのチームは継続的インテグレーションから始めますが、これは一般的に開発者が自動テストを担当しているためです。
  • ただし、リリースの処理も担当している場合は、それを先に自動化することで時間を節約し、CI プロセスの構築に専念することができます。