『継続的デリバリー 信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化』 で初めて定義されたコンセプト

デプロイメントパイプラインが変更を承認すれば、本番環境に変更をデプロイする前にそれ以上テストする必要がなく、承認をもらう必要もなく、システムの他の部分とのインテグレーションテストも不要である

デプロイ可能なソフトウェアユニットの単位で評価する必要がある

2 つの方法

システムに含まれるすべてのものを評価のスコープ、デプロイメントパイプラインのスコープに収める

システムを独立してデプロイ可能なソフトウェアユニットに分割する

参考文献

ソフトウェアをバージョン管理から取り出して、ユーザーの手に渡るまでのプロセスを自働化して表現したもの

デプロイメントパイプラインでモデル化されるプロセスは、バリューストリームマップでモデル化されるプロセスの一部

あらゆるプロジェクトで共通のサブセットは次のとおり

コミットステージ : コンパイルし、自動テストスイートを通し、コード解析を実行

役に立つメトリクス : テストカバレッジ、重複コードの量、サイクロマチック複雑度、求心性結合と遠心性結合、警告の数、コードスタイル

自動受け入れテストステージ : システムが動くことを機能および非機能レベルで検証

ユーザーのニーズと顧客の仕様を満たす振る舞いをすることを確認する

手動テストステージ : システムが使いやすいか、要件を満たしているか検証し、自動テストで捉えられない欠陥を検出し、ユーザーに価値を提供することを確認する

通常、探索的テスト環境やインテグレーション環境、ユーザー受け入れテスト環境が含まれる

リリースステージ : システムをユーザーにデリバリーする

プラクティス

バイナリをビルドするのは 1 回だけにする (ソースコードを何度もビルドするようなビルドシステムが多い)

あらゆる環境に対して同じやり方でデプロイする

アプリケーションのデプロイには、アプリケーションが稼働していることを確かめるスモークテストを実施すべし

本番環境のコピーにデプロイする

各変更はすぐにパイプライン全体を通るように

パイプラインのどのステージでも失敗したらラインを止めるべし

継続的インテグレーションサーバーと同様に変更を待ち受け、一連の検証手順を実行しながら、それぞれをより高度化させる

継続的デリバリーのプラクティスは、デプロイメントパイプラインをテストやプロビジョニング、デプロイメントといった一般的な作業を自動化する仕組みとして使うことを支援する

デプロイメントパイプラインの機能を提供するツールの例 : Jenkins、ThoughtWorks の Go、Concourse、Bamboo、Microsoft の Team Foundation Server、TeamCity、GitLab CI など