連続配信は実際にはどのように機能しますか？

継続的デリバリーは良さそうに聞こえますが、私のソフトウェア開発経験の年は、実際には機能しないことを示唆しています。

（編集：明確にするために、私は常に多くのテストを自動的に実行しています。私のチェックは、各チェックインで自信を得る方法についてです。これは完全な形式のCDであると理解しています。 。毎週（一部は正しく行われればまだCDであると考えるかもしれません）、2週間、または1か月の繰り返しです。

• 完全なテストカバレッジは不可能です。あなたは多くの時間を費やす必要があります-そして、時間はお金です-すべての小さなもののために。これは貴重ですが、他の方法で品質に貢献するために時間を費やすことができます。
• 自動的にテストするのが難しいものもあります。たとえば、GUI。Seleniumでさえ、GUIが不安定かどうかはわかりません。かさばるフィクスチャがないと、データベースアクセスをテストするのが難しく、データストレージの奇妙なコーナーケースをカバーすることさえできません。同様に、セキュリティや他の多くのもの。事実上単体テストが可能なのは、ビジネスレイヤーコードのみです。
• ビジネス層でも、テスト目的で引数と戻り値を簡単に分離できる単純な関数はありません。モックオブジェクトの作成に多くの時間を費やすことができますが、これは実際の実装とは異なる場合があります。
• 統合/機能テストは単体テストを補完しますが、通常は各テストでシステム全体を再初期化する必要があるため、実行に時間がかかります。（再初期化しないと、テスト環境に一貫性がなくなります。）
• リファクタリングまたはその他の変更により、多くのテストが中断されます。それらを修正するのに多くの時間を費やします。意味のある仕様の変更を検証することであれば問題ありませんが、実際には重要な情報を提供するものではなく、意味のない低レベルの実装の詳細のためにテストが中断することがよくあります。多くの場合、微調整は、テスト対象の機能を真に確認することではなく、テストの内部構造を修正することに焦点を当てています。
• バグに関するフィールドレポートは、コードの正確なマイクロバージョンと簡単には一致しません。

私の長年のソフトウェア開発経験は、実際には機能しないことを示唆しています。

試しましたか？デイブと私は、私たち自身とThoughtWorksの他の年長者の両方の長年の経験に基づいて本を書き、実際に私たちが議論したことをやっています。この本には投機的なものはありません。私たちが議論するすべては、大規模な分散プロジェクトでも試され、テストされています。しかし、私たちはあなたがそれを信仰にとることを勧めません。もちろん、自分で試してみて、他の人があなたの経験から学ぶことができるように、関連するコンテキストを含めて、見つけたものとそうでないものを書き留めてください。

継続的デリバリは、自動化されたテストに重点を置いています。本の約3分の1を費やして話しています。これは、代替手段（手動テスト）が高価でエラーが発生しやすく、実際には高品質のソフトウェアを構築するのに最適な方法ではないためです（デミングが述べたように、「品質を達成するために質量検査に依存しないでください。そもそも製品」）

完全なテストカバレッジは不可能です。あなたは多くの時間を費やす必要があります-そして、時間はお金です-すべての小さなもののために。これは貴重ですが、他の方法で品質に貢献するために時間を費やすことができます。

もちろん、完全なテストカバレッジは不可能ですが、代替手段は何ですか？テストカバレッジはゼロですか？トレードオフがあります。その間のどこかがあなたのプロジェクトの正解です。一般に、自動化されたテストの作成または保守に費やす時間の約50％を費やすと予想されるはずです。包括的な手動テストのコストと、ユーザーに伝わるバグを修正するコストを考慮するまで、それは高価に聞こえるかもしれません。

自動的にテストするのが難しいものもあります。たとえば、GUI。Seleniumでさえ、GUIが不安定かどうかはわかりません。

もちろん。ブライアンマリックのテスト作業領域をご覧ください。探索的テストとユーザビリティテストを手動で実行する必要があります。しかし、それは、回帰テストではなく、高価で価値のある人間を使用するべきものです。重要なのは、包括的な自動テストスイートに合格したビルドに対して、高価な手動検証のみを実行するように、展開パイプラインを配置する必要があることです。したがって、手動テストに費やすお金の量と、手動テストまたは実稼働に至るまでのバグの数を減らすことができます（それまでに修正するには非常に費用がかかります）。自動化されたテストは、製品のライフサイクル全体ではるかに安くなりますが、当然のことながら、時間の経過とともに償却される設備投資です。

かさばるフィクスチャがないと、データベースアクセスをテストするのが難しく、データストレージの奇妙なコーナーケースをカバーすることさえできません。同様に、セキュリティや他の多くのもの。事実上単体テストが可能なのは、ビジネスレイヤーコードのみです。

データベースアクセスは、エンドツーエンドのシナリオに基づく機能的受け入れテストによって暗黙的にテストされます。セキュリティには、自動化されたテストと手動のテストの組み合わせが必要になります-自動化された侵入テストと静的解析（たとえば、バッファオーバーラン）。

ビジネス層でも、テスト目的で引数と戻り値を簡単に分離できる単純な関数はありません。モックオブジェクトの作成に多くの時間を費やすことができますが、これは実際の実装とは異なる場合があります。

もちろん、ソフトウェアとテストをひどくビルドすると、自動化されたテストは高価になります。「テストによって導かれるオブジェクト指向ソフトウェアの成長」という本を読んで、テストとコードを長期間維持できるようにする方法を理解することを強くお勧めします。

統合/機能テストは単体テストを補完しますが、通常は各テストでシステム全体を再初期化する必要があるため、実行に時間がかかります。（再初期化しないと、テスト環境に一貫性がなくなります。）

私が取り組んでいた製品の1つには、実行に18時間かかる3,500のエンドツーエンドの受け入れテストがあります。70個のボックスのグリッドで並行して実行し、45mでフィードバックを取得します。本当に理想よりも長いため、ユニットテストが数分で実行された後、パイプラインの第2ステージとして実行するため、基本レベルのないビルドでリソースを無駄にしない信じる。

リファクタリングまたはその他の変更により、多くのテストが中断されます。それらを修正するのに多くの時間を費やします。意味のある仕様の変更を検証することであれば問題ありませんが、実際には重要な情報を提供するものではなく、意味のない低レベルの実装の詳細のためにテストが中断することがよくあります。多くの場合、微調整は、テスト対象の機能を真に確認することではなく、テストの内部構造を修正することに焦点を当てています。

コードとテストが適切にカプセル化され、疎結合されている場合、リファクタリングは多くのテストを中断しません。機能テストでも同じことを行う方法を本で説明しています。受け入れテストが失敗した場合、それは1つまたは複数の単体テストが欠落していることを示しています。そのため、CDの一部には、テストがよりきめ細かく配信プロセスの早い段階でバグを見つけて見つけるために、テストカバレッジを絶えず改善することが含まれますバグの修正は安価です。

バグに関するフィールドレポートは、コードの正確なマイクロバージョンと簡単には一致しません。

より頻繁にテストしてリリースする場合（CDのポイントの一部）、バグの原因となった変更を特定するのは比較的簡単です。CDの重要なポイントは、フィードバックサイクルを最適化して、バグをバージョン管理にチェックインした後、できるだけ早くバグを特定できるようにすることです。実際、バグをチェックインする前に（これがビルドテストとユニットテストを実行する理由です）チェックイン前）。

最初に、CDは1つの大きな精神的調整を必要とします。結局のところ、あなたは否定を証明することはできません。

これを超えると、a）これらのエラーを非常にすばやくキャッチし、b）非常に効率的に更新をロールバックまたは展開するためのツールと手順が必要であることがわかります。さらに、本当にCDカクテルを飲んでいる場合は、ロールバックしやすく、アプリケーション全体に及ぶ大きなバグを導入できないはずの、小さくて先の尖った変更を大量に提供していることになります。CDを実際に練習している人でさえ、主要な切り替えをより伝統的な方法で処理しています。

すべてのシステムにはリスクがあり、すべてのリスクには潜在的なコストがあります。広範なテストとQAで見つけるのに数か月または数年かかるような小さなリスクのコストが十分に高い場合（心臓ペースメーカーのソフトウェア）、長期間のテストなしに出荷しないでください。冷凍リリース。失敗のコストが十分に小さい場合は、テストなしで継続的に出荷することがあります（猫のFacebookページ）。

完全なテストカバレッジは不可能です。あなたは多くの時間を費やす必要があります-そして、時間はお金です-すべての小さなもののために。これは貴重ですが、他の方法で品質に貢献するために時間を費やすことができます。

100％のカバー率は必要ありません。システムに自信を持っている必要があります。1つの場所に変更しても、以前に作業したことが証明されているものを壊しません。

自動的にテストするのが難しいものもあります。たとえば、GUI。Seleniumで
さえ、GUIが不安定かどうかはわかりません。データベースアクセスは、かさばるフィクスチャなしでテストするのは難しく、それでもデータストレージの奇妙なコーナーケースはカバーしません。

ただし、データベースへのアクセスは簡単です。データを取得および設定するだけなので、データレイヤーで多くのテストを行う必要はありません。最も重要なことは、失敗した場合、問題をロールバックしてログに記録し、修正できるようにすることです。

同様に、セキュリティや他の多くのもの。事実上単体テストが可能なのは、ビジネスレイヤーコードのみです。ビジネス層でも、テスト目的で引数と戻り値を簡単に分離できる単純な関数はありません。

次に、多くの関数/クラスが大きすぎます。それらはテスト可能なように書かれるべきです。

モックオブジェクトの作成に多くの時間を費やすことができますが、これは実際の実装とは異なる場合があります。

ただし、モックオブジェクトのI / Oは予想されるものと一致する必要があります。その内部で起こることは重要ではありません。

統合/機能テストは単体テストを補完しますが、通常は各テストでシステム全体を再初期化する必要があるため、実行に時間がかかります。（再初期化しないと、テスト環境に一貫性がなくなります。）

これらは常に実行されるべきではありません。必要に応じて。

リファクタリングまたはその他の変更により、多くのテストが中断されます。それらを修正するのに多くの時間を費やします。意味のある仕様の変更を検証することであれば問題ありませんが、実際には重要な情報を提供するものではなく、意味のない低レベルの実装の詳細のためにテストが中断することがよくあります。多くの場合、微調整は、テスト対象の機能を真に確認することではなく、テストの内部構造を修正することに焦点を当てています。

次に、コードが密結合されすぎて、テストの記述が不十分になります。

バグに関するフィールドレポートは、コードの正確なマイクロバージョンと簡単には一致しません。

ここで何が得られているのか分かりませんか？バグがある場合は、その存在を示すテストを作成して修正します。

私たちにとってはうまくいきますが、私たちの顧客はほとんどが内部です。日中に複数のビルドが行われ、壊れたビルドは許容されず、Web起動メカニズムが使用されるため、ユーザーは起動ごとに最新バージョンを取得します。1つのことは、CDによって多くの問題が解消されることです。はい、常に互換性の問題がありますが、毎回小さな変更を展開するだけなので、問題は簡単に解決できます。CDのストレスレベルは、大きな更新を行ったときよりもはるかに低く、破損の場合にレビューするコードが非常に多いため、すべてが適切であると期待する必要がありました。

正直に言うと、すべてのソフトウェアは継続的に配信されています！最も重要なことは、それをドアから出すことです！ユーザーにそれを使用してもらい、その後、機能リクエストとバグ退治に優先順位を付けます。

「本物のアーティストが出荷」
-スティーブジョブズ。