デイリービルドと継続的インテグレーションに適したソフトウェアモデルは何ですか？
joel test と daily builds について読んだところ、さまざまな企業の技術リーダーの友人との話し合いで、毎日のビルドや継続的インテグレーションを行ったことがないことが明らかになりました。彼らへ：
- デイリービルドは、アジャイルプラクティスに従ったプロジェクトを対象としていました。ウォーターフォールモデルでは機能しません。
- 継続的な統合には、OpenGL/OGRE/OSGタイプのグラフィックプロジェクトでは使用できない自動テストが必要でした。これは、グラフィックパーツが（再）開発中のプロジェクトでは、明らかに自動テストが実用的でないためです。
- そのうちの1人は、構成管理を行う必要はないと考えています。小さな2〜3日のタスクを定義し、各タスク（コード、コードレビュー、ユニットテスト、統合）の開発サイクルのすべてのアクティビティを実行し、統合ストリームに配信してビルドおよび生成するという、哲学に従うだけで十分です。セットアップ。
- ビルドとCDへの書き込みプロセス全体のスクリプトを作成したとしても、作成するプログラムでは、実行する必要のあるテストとテストケースのスクリプトを作成する必要があるため、自動テストの作成は問題でした。時間がかかりすぎて、自動化されたテストツールが、実行する特定の種類のテストを常にサポートするとは限りません。
デイリービルドと継続的インテグレーションは、アジャイルでないプロジェクトにとって本当に実用的ですか？テスト駆動開発のみを対象としていますか？そして、ポイント3（上記）の種類の哲学に従うことで本当に十分でしょうか？ Joelが話している、組み込みのワンステップのスクリプト化された自動化について話していましたが、彼らはそのアイデアを購入する気がありませんでした。
pS：私は毎日のビルドなどについてこのサイトで質問を受けてきましたが、この質問は違うと思います。
編集：ポイント3は、「構成マンガと開発ツールを統合する必要はないと考えている人の1人」から始めるべきでした。
あなたの友達は怠惰でIMOは専門家ではありません-世界はすぐに彼らを通り過ぎます。
デイリービルドは、アジャイルプラクティスに従ったプロジェクトを対象としていました。ウォーターフォールモデルでは機能しません。
明確なリファレンスは手元にありませんが、デイリービルドは少なくとも90年代までは一般的だったため、アジャイルと* UnifiedProcessのタイムラインよりも前のものです。開発者が2人以上いる場合はいつでも、誰かがテスト可能なものをチェックインすると同時に、ビルドを中断するためのチェックを自動化できるようになりました。
自動化されたテストは、グラフィックス部分が...
自動テストは時間とコストを節約するツールです。なぜ誰かがソフトウェアを必要以上に高価にしたいのでしょうか？
構成管理が不要
それは明らかにクレイジーです。開発者は全員、異なるバージョンのサードパーティライブラリを使用していますか？各リリースで展開する機能を追跡する人はいませんか？バージョン管理システムに分岐機能はありませんか？
ディスカッションパートナーに公平を期すために、彼らが持っているものがうまくいくなら、まあ、それはうまくいきます。おそらく何らかの形でCIを販売することになるでしょうが、抵抗は理解できます。
そもそもCIを設定するためのオーバーヘッドと、それを管理するためのオーバーヘッドがあります。頭上ではそれほど大きなことではありませんが、ある時点でそれが不要な雑用になることがわかっているので、「CIの男」になることを拒否します。
ただし、構成するために他の誰かを指名したら、少なくとも、チェックインしたコードがコンパイルされていることを知っておくと便利です。その1つの利点だけでも重要です。
ここでは、テスト側は関係ありません。 CIビルドはテストを実行する必要がありますが、それらのテストが有用な目的を果たさない場合、それらのテストは存在してはなりません。ただし、常に意味のあるテストケースがあります。これは、多くの開発者にとって抵抗のポイントでもあります。
一部の人々は、コードテストカバレッジをプロジェクトの健全性の黄金の統計と見なしています。そうではありません。 「1か所が適切で品質の高いテストである」という1か所のカバレッジがまだあります。「80か所のカバレッジに到達する必要があるために書いたテスト」の80か所のカバレッジではありません。
そしてそれが最後の問題です。 CIを取得すると、誰かがカバレッジ統計を要求し、次にカバレッジが高くない理由を尋ね、次に誰かが自動化する優れたUIテストパッケージへのリンクを送信します...彼らの心の中でそれらは、明らかに機能するプロセスから、以前に提供していたのと同じ機能コードである同じ最終結果を得るのにより多くの労力を必要とするプロセスに移行しました。
デイリービルドは、アジャイルプラクティスに従ったプロジェクトを対象としていました。ウォーターフォールモデルでは機能しません。
純粋な滝は、ライフタイムが非常に小さいため、デイリービルドのセットアップが特大になるような些細なプロジェクト以上には機能しません。ただし、プロジェクトの存続期間が少なくとも数か月で、「繰り返しサイクルのあるウォーターフォール」を意味する場合は、当然、毎日のビルドは非常に理にかなっています。そして、分析、設計、開発フェーズがある従来のウォーターフォールでも、開発フェーズでは多くのビルドとコード統合を行わなければならないので、これを自動化して、コードの変更が毎日統合されるようにしてください。
継続的インテグレーションには自動テストが必要
ナンセンス、CIは自動テストを統合できますが、それは必須ではありません。手動でテストし、CIを使用できるのは、テスターのデイリービルドの準備ができていることを確認するためだけです。
そのうちの1人は、構成管理を行う必要はないと考えています。
製品のライフサイクルがリリース1.0の後に終了するプロジェクトがある場合、これは当てはまります。他のすべてのケースでは、何らかの構成管理が必要です。しかし、これはCIから独立しています。さらに、CIは、コードベースへの変更を小さく保ち、毎日再統合することをお勧めします。
ビルドとCDへの書き込みプロセス全体のスクリプトを作成したとしても、自動テストの作成は問題でした
私のコメントを参照してください。CIは自動テストを必要としません。
そしてあなたの他のポイントへ：
実行する必要のあるテストを常に把握できるとは限りません
それらのすべて、他に何がありますか？
テストケースのスクリプト作成には時間がかかりすぎる
手動で何度も何度も適用するのに時間がかかりすぎるテストケースをスクリプト化する必要があるため、自動化すると節約時間がかかります。
自動テストツールは、実行したい特定の種類のテストを常にサポートするとは限りません。
自動化するのに問題があるいくつかの可能なテストがあるので、何も自動化しませんか？私にはあまり説得力がないようです。そして、自動テストには特別なツールが必要だと誰が言ったのですか？ツールを使わずに、または軽量のxUnitフレームワークだけを使って始めます。
うわー、どこから始めますか？私の個人的な見解では、あなたが話していた友達は、経験ベースや定義が比較的狭いということです。私は石油とガスで働いていないので、他のエンジニアがSCADAに実際に取り組むことができないと主張するとき、私は毎日それを目にします。それは彼らが宗教の信念をもって持ち運ぶ過度に狭い定義であり、それは彼らを迷わせます。
- 重要なインフラストラクチャシステムの開発、配信、およびサポートの25年間で、基本的にすべての製品開発または配信プロジェクトは、正式には「ウォーターフォール」プロジェクトでした。 。一部の業界は単にそのようです。しかし、実践者として：私は欠けている最も重要な機能に基づいて小さな目標を設定し、それを実現するためのテストを作成し、それらのテストに合格するためのコードを記述します。コードの記述によって追加のテストが行われることがあり（通常はすべてのエラー処理に対して）、エラートラップを事後に追加するよりも拡張する方が簡単なため、通常は実際の機能の前にエラー処理を作成してテストしようとします。
定期的なシステムビルドは、活発な開発が行われているときは常に作業の一部であり、私の初期のキャリアの責任の1つは、金曜日の午後5時頃にシステムビルドを開始し、約24時間後にチェックすることです。 （金曜日の夜に物事が横向きになった後、必要に応じて日曜日を使用して再構築しました。）週中のコーダーのコンパイルは、金曜日の正午までに必須のチェックインがある個々のプロセスまたはサブシステムに制限されていたため、システム構築は時間どおりに開始できました。 。正直なところ、チームリーダーとプロジェクトリーダーは、lovedで毎日のビルドを利用できるため、毎日のビルドは「アジャイル「方法論は私を圧倒するように感じます。
- グラフィックベースのUIの自動テストは問題領域です。 UIの基盤となるテクノロジが、データ要素とコントロールを十分に公開していないため、名前で表示要素をアドレス指定し、プログラムで値を読み取ることができない場合、画面のスクレイピングや、ユーザビリティの移動や情報の再フォーマットのための小さな調整が必要です。 UIテスト自動化への入力である画面スクレイピングステップを中断します。
個人的な意見：自動化処理とテスト計画のUIを区別し、自動化テストを自動化処理の証明に集中させます。自分が得意なグラフィカルな認識を人々に行わせます。マシンにグラフィカルな認識を強制し、可能な唯一のテストを主張することは、UIがソフトウェアの設計と開発の現実を通常よりも無視することです。 （エンジニアはすでにテストを書くのが苦手です。実行可能なツールを禁止するほど愚かであってはなりません！）
構成管理は、手段の組み合わせによって実現できます。現在のシステムビルドは、インストールされたシステムの上に5〜10分で完了して展開するのに6〜8時間かかります。デプロイメントでは、必須のサードパーティ製品を含む90以上のソフトウェアラインアイテムのすべてが正しいかどうかをチェックしません。これは、それらを異なるメカニズムで管理し、ビルドのインストールツールでこれらのアイテムすべてをインストールするのは非常にコストがかかるためです。代わりに、多くの広告申込情報はシステムビルドによって変更されず、サーバーの作成時に個別にインストールされます。完璧ではありませんが、重要なインフラストラクチャコードの制御には、すべての自動自己更新機能のブロックと、ソフトウェアのすべてのラインアイテムの更新の計画と実施を担当することが含まれます。少なくとも、適切な更新サイクルで各ラインアイテムを処理し、アップグレードされた組み合わせを検証することができます。たとえば、データモデリングによって制御される機能は、コードよりも頻繁に更新多くされ、アプリケーションコードはOSバージョンより頻繁に更新されます。 3つの異なるツールが適切であるため、それぞれが適切に処理されます。したがって、CMは必須ですが、すべてのアイテムを1つのツールに配置する必要があるという意味ではありません。関連するライフサイクルを学び、理解し、各部分を適切な方法とチームに割り当てます。
スクリプトテストケースは、経済的に証明可能なポイントです。各顧客とリリースの手動回帰テストのコストはいくらですか？ 30日または90日ごとにパッチを適用する必要があるソフトウェアシステムで実行するのに数人年を必要とするテストスイートをよく目にします。ユーザーがバグを見つけた場合の費用はいくらですか？それぞれはどのくらいの頻度で発生しますか？非常に迅速に、手動テストのコストとして、またはテストしない場合のコストとして、驚くほど大きな金額を思い付くことができます。もちろん、スクリーンスクレイピングを余儀なくされた場合、テストのコストも非常に急速に高くなる可能性があるため、許容可能なコストで価値を提供するテスト方法を特定し、それらの実装に集中する必要があります。顧客または製品マネージャーが適切なツールセットを取得して適用することをいとわない場合は、最小限の時間と計算リソースでテストケースを計画する必要があります。テストケースの形式化をスキップしないでください。これは誤った保存であり、最終的にはあなたを苦しめることになります。
これは、テストを適切なリリースに一致させる問題に対処していません。幸い、その問題はバージョン管理システムですでに解決されています。私が最近CMで取り組んだ1つのシステムでは、サーバーの役割ごとに一意の展開が必要でしたが、展開手順を完全に一般化することができなかったため、手順はリリースごとに部分的に一意である必要がありました。直接的な解決策は、リリースとバージョン管理にスクリプトを含めることでした。各リリースが確定するたびに、特定のバージョンのビルドをインストールするためのスクリプトが作成され、ビルドテストにはテストサーバーへのデプロイメントが含まれる場合があります。
多くのテストでは、同様のことを行うことができます。テストスクリプトを製品リリースキットにバンドルします。その後、CIパイプラインの一部としてのテストは、テストシェルのコンパイルとリンク、パッケージ化、デプロイ、実行になります。
私の意見が彼らの意見とほとんど反対であることから明らかなように、私の経験はあなたの友人の経験とはかなり異なっています。 CIは、ウォーターフォールの各ステップ内で個々のプラクティスがアジャイルであるのと同じように、ウォーターフォールプロジェクトの一部になります。この理念を使用すると、合理的に予測可能な時間内に信頼性の高い作業成果物を提供し、最終製品の品質を回帰から保護できるため、非常に実用的です。重要なインフラストラクチャを構成する大規模な設計システムでも、必要な機能はプロジェクトの途中で変化する可能性があり、ユーザーはプロジェクトの変更命令とスコープネゴシエーションを必要とするものについて考えを変えることができます。変更の処理が不十分であり、プロジェクトが軌道に乗っているのではなく、雑草の中にいる。アジャイルプラクティスとは、使用中のシステムとテクノロジーの変更を可能な限り効果的に処理することであり、適用するものを選択することは、プロジェクトの規模と組織の能力の成熟度に意味をなさなければなりません。
RE：グラフィックシステムなど、指定が困難でテストが困難なシステムのテスト。
私の経験では、テストは構築しているシステムの出力をテストすることだけではありません（？）それは、あなたが行った仮定が正しいことを検証し、プロジェクトが発展し状況が変化するにつれてそれらの仮定を検証し続けることです。
このため、コード内のさまざまなポイントに適度な数のアサーションステートメントを配置することは、継続的な統合体制と組み合わせると非常に大きなメリットがあります。
システムは、ユニットテストの包括的なスイートで実行する必要はありません（ただし、時間があれば良いものです）、激しいシステムレベルの演習の小さなセットでさえ、途方もないものを提供しますバグを発見し、自信を構築するためのユーティリティ。