継続的デリバリーは実際にはどのように機能しますか？
継続的デリバリーは良さそうですが、私の長年のソフトウェア開発経験から、実際には機能しないことがわかります。
（編集：明確にするために、私は常に多くのテストを自動的に実行しています。私の質問は、各チェックインで確実に配信する方法についてです。これは、完全な形式のCDであると理解しています。代替手段は、1年のサイクルではありません。 。これは、毎週（正しく行われた場合はまだCDと見なされる場合もあります）、2週間、または1か月の繰り返しです。自動テストを補足する、各週の終わりに旧式のQAを含めます。）
- 完全なテストカバレッジは不可能です。あなたは多くの時間を費やさなければなりません-そして時間はお金です-すべての小さなことのために。これは貴重ですが、時間は他の方法で品質に貢献することに費やされる可能性があります。
- 自動的にテストするのが難しいものもあります。例えば。 GUI。 Seleniumでも、GUIが不安定であるかどうかはわかりません。かさばるフィクスチャがないと、データベースアクセスをテストするのは難しく、データストレージの奇妙なコーナーケースもカバーできません。同様に、セキュリティと他の多くのもの。ビジネス層コードのみが効果的に単体テスト可能です。
- ビジネス層でも、ほとんどのコードには、テストのために引数と戻り値を簡単に分離できる単純な関数はありません。モックオブジェクトの作成には多くの時間を費やす可能性があり、実際の実装とは一致しない場合があります。
- 統合/機能テストは単体テストを補足しますが、通常は各テストでシステム全体を再初期化する必要があるため、実行に長い時間がかかります。 （再初期化しないと、テスト環境に一貫性がなくなります。）
- リファクタリングやその他の変更により、多くのテストが失敗します。あなたはそれらを修正するのに多くの時間を費やします。意味のある仕様変更を検証することで問題ない場合は問題ありませんが、重要な情報を実際に提供するものではなく、意味のない低レベルの実装の詳細のためにテストが失敗することがよくあります。多くの場合、調整は、テストされている機能を実際にチェックすることではなく、テストの内部を再構築することに焦点が当てられています。
- バグに関するフィールドレポートは、コードの正確なマイクロバージョンと簡単に照合することはできません。
私の長年のソフトウェア開発経験から、実際には機能しないことがわかります。
試しましたか？デイブと私は、ThoughtWorksの私たち自身や他の高齢者の多くの集合的な長年の経験に基づいて本を書き、実際に私たちが議論することを行いました。本の何も推測ではありません。私たちが議論することはすべて、大規模な分散プロジェクトでも試され、テストされてきました。しかし、あなたがそれを信仰に基づいて服用することは勧めません。もちろん自分で試してみてください。他の人があなたの経験から学べるように、関連するコンテキストを含めて、うまくいったこととうまくいかないことを書いてください。
継続的デリバリーは自動テストに大きな焦点を当てています。本の約3分の1を費やしています。これを行うのは、代替手段-手動テスト-が高価でエラーが発生しやすく、実際に高品質のソフトウェアを構築する優れた方法ではないためです（デミングが言ったように、「品質を達成するために大量検査への依存をやめる。プロセスを改善し、品質をそもそも製品」）
完全なテストカバレッジは不可能です。あなたは多くの時間を費やさなければなりません-そして時間はお金です-すべての小さなことのために。これは貴重ですが、時間は他の方法で品質に貢献することに費やされる可能性があります。
もちろん、完全なテストカバレッジは不可能ですが、代わりの方法は何ですか？トレードオフがあります。中間のどこかがプロジェクトの正しい答えです。一般に、自動テストの作成または保守に時間の約50％を費やすと予想すべきであることがわかります。包括的な手動テストのコスト、およびユーザーに発生するバグの修正のコストを検討するまで、これは高額に聞こえるかもしれません。
自動的にテストするのが難しいものもあります。例えば。 GUI。 Seleniumでも、GUIが不安定であるかどうかはわかりません。
もちろん。ブライアン・マリックのテスト象限をご覧ください。探索的テストとユーザビリティテストを手動で実行する必要があります。しかし、それは回帰テストではなく、高価で価値のある人間を使用するためのものです。重要なのは、デプロイメントパイプラインを配置して、包括的な自動テストスイートに合格したビルドに対して、高価な手動検証のみを実行する必要があることです。したがって、手動テストに費やす金額と、手動テストまたは本番環境に到達するまでに発生するバグの数の両方を削減します（その時点で、バグはvery修正に費用がかかります）。自動テストが適切に行われると、製品のライフサイクル全体ではるか安くなりますが、当然ながら、時間の経過とともに自己資本が償却されます。
かさばるフィクスチャがないと、データベースアクセスをテストするのは難しく、データストレージの奇妙なコーナーケースもカバーできません。同様に、セキュリティと他の多くのもの。ビジネス層コードのみが効果的に単体テスト可能です。
データベースアクセスは、エンドツーエンドのシナリオベースの機能受け入れテストによって暗黙的にテストされます。セキュリティでは、自動テストと手動テストの組み合わせが必要になります。たとえば、バッファオーバーランを見つけるための自動侵入テストと静的分析です。
ビジネス層でも、ほとんどのコードには、テストのために引数と戻り値を簡単に分離できる単純な関数はありません。モックオブジェクトの作成には多くの時間を費やす可能性があり、実際の実装とは一致しない場合があります。
もちろん、自動化されたテストは、ソフトウェアとテストをひどく構築した場合にはコストがかかります。テストとコードを長期にわたって維持できるように正しく実行する方法を理解するには、本「成長するオブジェクト指向ソフトウェア、テストガイド付き」をチェックすることを強くお勧めします。
統合/機能テストは単体テストを補足しますが、通常は各テストでシステム全体を再初期化する必要があるため、実行に長い時間がかかります。 （再初期化しないと、テスト環境に一貫性がなくなります。）
以前使用していた製品の1つに、実行に18時間かかる3,500のエンドツーエンドの受け入れテストスイートがあります。 70箱のグリッド上で並行して実行し、45mでフィードバックを得ます。本当に理想よりもずっと長いので、ユニットテストが数分で実行された後、パイプラインの第2ステージとして実行するので、基本的なレベルのないビルドでリソースを無駄にしません。信じる。
リファクタリングやその他の変更により、多くのテストが失敗します。あなたはそれらを修正するのに多くの時間を費やします。意味のある仕様変更を検証することで問題ない場合は問題ありませんが、重要な情報を実際に提供するものではなく、意味のない低レベルの実装の詳細のためにテストが失敗することがよくあります。多くの場合、調整は、テストされている機能を実際にチェックすることではなく、テストの内部を再構築することに焦点が当てられています。
コードとテストが適切にカプセル化され、疎結合されている場合、リファクタリングによって多くのテストが中断されることはありません。機能テストでも同じことを行う方法を本で説明しています。受け入れテストが失敗した場合、それは1つ以上の単体テストが欠落していることを示しているため、CDの一部には、テストカバレッジをより細かくし、配信プロセスの早い段階でバグを見つけるためのテストカバレッジの継続的な改善が含まれます。バグを修正する方が安価です。
バグに関するフィールドレポートは、コードの正確なマイクロバージョンと簡単に照合することはできません。
テストとリリースをより頻繁に行う場合（CDのポイントの一部）、バグの原因となった変更を特定するのはis比較的簡単です。 CDの目的は、フィードバックサイクルを最適化して、バージョン管理にチェックインした後、できるだけ早くバグを特定できるようにすることです。実際には、チェックインする前に（できれば、ビルドテストとユニットテストを実行するのはそのためです）チェックイン前）。
まず、CDは1つの大きな精神的調整を必要とします-何をしても、時々物事が壊れてしまうことを認めなければなりません。結局のところ、ネガティブなことを証明することはできません。
これを乗り越えると、a）これらのエラーを非常に迅速にキャッチし、b）更新を非常に効率的にロールバックまたは展開するためのツールと手順が必要であることがわかります。さらに、本当にCDカクテルを飲んでいる場合は、ロールバックが簡単で、アプリケーション全体に大きなバグが発生することはないはずの、小さな、先の尖った変更をたくさん提供していることになります。 CDを本当に練習している人でさえ、従来の方法で主要な切り替えを処理しています。
すべてのシステムにはリスクがあり、すべてのリスクには潜在的なコストがあります。広範なテストとQAで見つけるのに数か月または数年かかるような小さなリスクのコスト（心臓ペースメーカーのソフトウェア）が十分に高い場合、冷凍リリース。失敗のコストが十分に小さければ、テストなしで継続的に出荷できます（猫のFacebookページ）。
完全なテストカバレッジは不可能です。あなたは多くの時間を費やさなければなりません-そして時間はお金です-すべての小さなことのために。これは貴重ですが、時間は他の方法で品質に貢献することに費やされる可能性があります。
100％のカバレッジは必要ありません。システムに自信を持っている必要があります。1つの場所に変更を加えても、以前に実績のある作業は中断されません。
自動的にテストするのが難しいものもあります。例えば。 GUI。セレンもしません
GUIが不安定であるかどうかを教えてください。かさばるフィクスチャがないと、データベースアクセスをテストするのは難しく、データストレージの奇妙なコーナーケースもカバーできません。
ただし、データベースへのアクセスは簡単です。データを取得して設定するだけなので、データレイヤーで多くのテストを行う必要はありません。最も重要なことは、失敗したときに、ロールバックしてログに記録し、修正できるようにすることです。
同様に、セキュリティと他の多くのもの。ビジネス層コードのみが効果的に単体テスト可能です。ビジネス層でも、ほとんどのコードには、テストのために引数と戻り値を簡単に分離できる単純な関数はありません。
次に、多くの関数/クラスが大きすぎます。それらはテスト可能であるように書かれるべきです。
モックオブジェクトの作成には多くの時間を費やす可能性があり、実際の実装とは一致しない場合があります。
ただし、モックオブジェクトのI/Oは、予想されるものと一致する必要があります。重要ではない内部で何が起こるか。
統合/機能テストは単体テストを補足しますが、通常は各テストでシステム全体を再初期化する必要があるため、実行に長い時間がかかります。 （再初期化しないと、テスト環境に一貫性がなくなります。）
これらは常に実行する必要はありません。必要に応じて。
リファクタリングやその他の変更により、多くのテストが失敗します。あなたはそれらを修正するのに多くの時間を費やします。意味のある仕様の変更を検証することで問題ない場合は問題ありませんが、重要な情報を実際に提供するものではなく、意味のない低レベルの実装の詳細のためにテストが失敗することがよくあります。多くの場合、調整は、テストされている機能を実際にチェックすることではなく、テストの内部を再構築することに焦点が当てられています。
次に、コードの結合が強すぎ、テストの記述が不十分です。
バグに関するフィールドレポートは、コードの正確なマイクロバージョンと簡単に照合することはできません。
ここで何を取得しているのかわかりませんか？バグがある場合は、その存在を示すテストを記述して修正します。
私たちにとってはうまくいきますが、私たちの顧客は主に内部にいます。日中に複数のビルドが行われ、壊れたビルドは許容されません。Web開始メカニズムが使用されるため、ユーザーは起動ごとに最新バージョンを取得します。 1つは、CDによって多くの問題が解消されることです。はい、常に互換性の懸念がありますが、毎回小さな変更を展開するだけなので、懸念は非常に簡単に処理できます。 CDのストレスレベルは、大きな更新を行ったときよりもはるかに低く、破損した場合に確認するコードが多すぎるため、すべてが適切であることを期待する必要がありました。