ソフトウェアエンジニアリングにおけるデプロイメントパイプライン (CI/CD)

デプロイメントパイプラインは、バージョン管理からコードを取得し、それを生産環境に届ける自動化されたプロセスです。どのソフトウェアエンジニアリングチームにおいても、適切に設計されたデプロイメントパイプラインは、 開発者 や DevOpsの専門家 が、スピードとスケールでコードを信頼性を持ってコンパイル、ビルド、テスト、デプロイできるようにします。

最も一般的なパイプラインのコンポーネントは、ビルド自動化/継続的インテグレーション、テスト自動化、およびデプロイ自動化であり、これらは5つのカテゴリーのツールによってサポートされています: ソース管理、ビルドツール、 コンテナ化、 構成管理、および監視です。

デプロイメントパイプラインとは何ですか？

デプロイメントパイプラインは、バージョン管理からコードを取得し、自動化された再現可能な方法でエンドユーザーに提供するプロセスです。デプロイメントパイプラインがなかった時代、ソフトウェアのリリースは手動プロセスであり、コミュニケーションのオーバーヘッドや人的エラーが発生しやすかったです。

主要な目的は完全な自動化です。パイプラインの任意の段階間に手動のステップや変更が必要ありません。繰り返しのタスクの手動実行は、納品物に影響を与える可能性のある人的エラーを引き起こす可能性があり、場合によってはデプロイメントの失敗や混乱によりSLAを侵害することがあります。

デプロイメントパイプラインの段階は何ですか？

一般的なデプロイメントパイプラインは、バージョン管理、受け入れテスト、独立したデプロイメント、本番デプロイメントの4つの段階を経ます。

一般的なデプロイメントパイプラインの段階は以下の通りです。

バージョン管理

受け入れテスト

受け入れテストは、ビジネスによって設定された事前定義された受け入れ基準を満たしていることを確認するために、コンパイルされたコードに対して一連の自動テストを実行するプロセスです。

独立したデプロイメント

本番デプロイメント

ソフトウェア開発者は、ソース管理（例: GitHub）にコード変更をコミットします。各コミットはデプロイメントパイプラインの最初のステージをトリガーし、コードのコンパイル、ユニットテスト、コード分析、およびインストーラーの作成を実行します。すべてのステップが成功裏に完了すると、実行可能ファイルがバイナリに組み込まれ、後で使用するためのアーティファクトリポジトリに保存されます。

独立したデプロイメントは、コンパイルされテストされたアーティファクトを開発環境にデプロイするプロセスです。これらの環境は、可能な限り本番環境に近いことが理想的であり、さらなる自動テストまたは手動テストを行う前に、本番に近いインフラ上でソフトウェアを機能的にテストできるようにします。

本番デプロイメントは通常、オペレーションまたはDevOpsチームによって管理されます。これは独立したデプロイメントと似たプロセスに従い、ライブの本番サーバーをターゲットにします。リスクを最小限に抑えるために、この段階では通常、青/緑のデプロイメントまたはカナリアリリースを使用します。これらはどちらも、予期しない問題が発生した場合にゼロダウンタイムのリリースと簡単なバージョンロールバックを可能にします。ゼロダウンタイムのデプロイメントが利用できない場合、リリースウィンドウは事前にビジネスとの合意によって設定されます。

CI/CDとは何ですか、そしてそれはデプロイメントパイプラインとどのように関連していますか？

CI/CD—継続的インテグレーションと継続的デリバリー—は、デプロイメントパイプラインを迅速、信頼性が高く、繰り返し可能にする実践です。

継続的インテグレーション (CI) は、開発者が1日に何度もバージョン管理されたリポジトリにコードをコミットする実践です。各チェックインによってトリガーされる自動ビルドパイプラインは、高速で正確なエラー検出を可能にします。CIの主な利点には、 より小さな変更が大規模なコードベースにより簡単に統合されること、 バグが早期に発見され、修正が安価になること、コード品質が一貫して検証されること、そして統合問題が少なくなることで迅速なデリバリーが可能であることが含まれます。

継続的デリバリー (CD) は、開発と運用のエンジニアがバグ修正、機能、および構成変更を本番環境に信頼性高く、迅速かつ持続可能に提供するプロセスです。主な利点には、 青/緑 および カナリアデプロイメントによって可能になるリスクの低いリリース、機能とバグ修正の迅速なデリバリー、そして ユーザーのフィードバック を早期に取り入れることで実現されるコスト削減が含まれます。

青/緑デプロイメントとは何ですか？

青/緑デプロイメントは、2つの鏡面本番環境を維持することによってリスクとダウンタイムを削減します。一方が「青」として指定され、もう一方が「緑」として指定され、いずれか一方がライブトラフィックを処理するだけです。

デプロイメント中、ソフトウェアは非ライブ環境にリリースされ、本番トラフィックは中断されることなく継続します。すべてのテストが合格した後、トラフィックのルーティングが更新された環境に切り替わります。次のデプロイメントサイクルでは、役割が逆転します: 以前のライブ環境がステージングターゲットになります。

カナリアデプロイメントとは何ですか？

カナリアデプロイメントは、青/緑デプロイメントとは異なり、並行して動作する2つの完全な複製環境を必要としません。代わりに、カナリアリリースは新しいバージョンを特定の数または割合のユーザーまたはサーバーに展開し、完全なロールアウトの前にライブプロダクションテストを可能にします。

カナリアリリースの主な利点は、早期の障害検出です: 問題が発生した場合、変更を迅速にロールバックでき、影響を受けるユーザーまたはサービスの数を制限できます。

CI/CDパイプラインを構築するために使用できるツールは何ですか？

信頼性が高く堅牢な CI/CD パイプラインを構築するために、いくつかの広く使用されているツールがあります。すべてのツールは無料のティアを提供しているため、始めるのが簡単です: 

• Jenkins
• Azure DevOps (旧VSTS)
• CodeShip

要約すると、CIはソフトウェア開発チームがコードをチェックインし、その品質を検証することを可能にする自動化プロセスです。CDは開発および運用チームが新機能やバグ修正をエンドユーザーに信頼性高く効率的に提供することを可能にします。

よくある質問

デプロイメントパイプラインとCI/CDパイプラインの違いは何ですか？

これらの用語はしばしば同義語として使用されますが、範囲が異なります。CI/CDパイプラインは特に継続的インテグレーション（コードコミット時の自動ビルドおよびテスト）と継続的デリバリー（自動リリースプロセス）をカバーしています。一方、デプロイメントパイプラインは、ソース管理からテスト環境を経て本番環境に至るまでのコードを移動する、より広範なエンドツーエンドシステムです。CI/CDはこれを実装するための一つのアプローチです。

デプロイメントパイプラインの段階が失敗した場合はどうなりますか？

任意の段階が失敗すると、ユニットテスト、コード分析チェック、または受け入れテストのように、パイプラインは停止し、変更は次の段階に進められません。開発者には通知が送られ、問題を修正し、パイプラインを再トリガーできます。このゲートベースのアプローチにより、壊れたコードが本番環境に到達するのを防ぎます。

デプロイメントパイプラインはどのようにデプロイメントリスクを軽減しますか？

リリースプロセスのすべての段階を自動化し、各段階間の品質ゲートを強制することによって、デプロイメントパイプラインは、ほとんどのデプロイメント失敗の原因となる手動エラーを排除します。青/緑デプロイメントやカナリアリリースは、予期しない問題が発生した場合にゼロダウンタイムのリリースと即時ロールバックを可能にすることによって、リスクをさらに軽減します。

アーティファクトリポジトリとは何ですか、そしてパイプラインに必要な理由は何ですか？

アーティファクトリポジトリは、コンパイルされた、テスト済みのビルド出力（バイナリ、パッケージ、またはコンテナイメージ）の保存場所です。デプロイメントパイプラインは、ビルド段階で検証されたアーティファクトをそこに保存し、下流の段階がソースから再コンパイルするのではなく、正確に同じ検証済みのビルドを使用できるようにすることで、一貫性を確保します。

デプロイメントパイプラインはコンテナ化なしで機能しますか？

はい。コンテナ化はデプロイメントパイプラインで一般的なツールカテゴリーですが、必須ではありません。パイプラインはコンテナ化よりも前から存在しています。ただし、コンテナは開発、ステージング、本番環境間の環境の均一さを達成するのを大幅に簡素化し、「私のマシンで動く」といったデプロイメントの失敗を減少させます。

関連するリーディング

• BMC DevOpsブログ
• DevOpsガイド、DevOpsに関する30以上の記事のシリーズ
• 継続的デリバリーとデプロイメント、継続的インテグレーションの違い
• ソフトウェアのデプロイとリリースの違い
• テスト自動化の説明: なぜ&どのようにテストを自動化するか
• シフトレフトテスト: 何、なぜ、どのようにシフトレフトするか

この投稿に表現されている見解や意見は著者のものであり、BMCの公式な立場を必ずしも反映するものではありません。

これらの投稿は私自身のものであり、必ずしもBMCの立場、戦略、または意見を表すものではありません。