継続的デリバリー

継続的なデリバリー パイプラインでは、本番環境の直前に手動ゲートを設置できます。手動ゲートには人間の介入が必要で、組織にはパイプラインに手動ゲートが必要なシナリオが存在する可能性があります。手動ゲートの中には不適正なものもあれば、適正なものもあります。適正なシナリオの 1 つとして、ビジネス チームが最後の段階でリリースの決定を下すというものがあります。各スプリントの後、エンジニアリング チームがリリース可能なバージョンの製品を準備して、ビジネス チームがすべての顧客または特定の顧客 (たとえば、特定の地理的場所に住む顧客) に製品をリリースする最終的な指示を出します。

パイプラインを流れる製品のアーキテクチャは、継続的なデリバリー パイプラインの構造を決定する重要な要素です。高度に結合された製品アーキテクチャは複雑なグラフィック パイプライン パターンを生成します。そこではさまざまなパイプラインが絡みあって、最終的な本番環境に向かいます。

また、製品のアーキテクチャはパイプラインのさまざまなフェーズに影響を与えて、各フェーズで生成されるアーティファクトにも影響します。パイプラインでは、最初にコンポーネントが構築されます。これは、製品の配布可能かつテスト可能な最小のユニットです。たとえば、パイプラインによって構築されたライブラリはコンポーネントと呼べます。これが、コンポーネント フェーズです。

疎結合のコンポーネントによって構築されるサブシステムは、デプロイおよび実行可能な最小単位です。たとえば、サーバーはサブシステムです。コンテナーで実行されるマイクロサービスもサブシステムの一例です。これが、サブシステム フェーズです。コンポーネントとは異なり、サブシステムは立ち上げ検証できます。

したがって、システム全体をリリースする必要がある場合は、パイプラインに指示して疎結合のサブシステムからシステムを組み立てられます。これが、システム フェーズです。

このすべてか無かのアプローチでは、最も遅いサブシステムが最も速いサブシステムのボトルネックとなります。私たちは「鎖の強さは最も弱いつなぎ目で決まる」という決まり文句によって、このアーキテクチャ パターンに陥るチームに警告しています。

検証が完了すると、組み立てられたシステムは、本番フェーズと呼ばれる最終フェーズでそれ以上変更を加えることなく本番環境に実装されます。

これらのフェーズは物理的というよりも論理的な性格が強く、大きな問題を複数の小さな問題に分割するためだけに作成される点にご注意ください。フェーズの数は、アーキテクチャと要件によって異なります。

いくらスピードが速くても品質が伴わなければ、お客様にとって役に立ちません。継続的なテストとは、自動テストをソフトウェア デリバリー パイプラインに統合して、そこに流れるすべての変更を検証する手法です。パイプラインの各フェーズでテストが実行されて、そのフェーズで生成されたアーティファクトが検証されます。単体テストと静的コード分析によって、パイプラインのコンポーネント フェーズのコンポーネントが検証されます。機能、パフォーマンス、セキュリティの各テストによってサブシステム フェーズのサブシステムが、統合、パフォーマンス、セキュリティの各テストによってシステム フェーズのシステムが、最後に、スモーク テストによって本番フェーズの製品が検証されます。