C＃ビルドマシンを設定する方法と理由は何ですか？
私は、C＃プロジェクトで小規模（4人）の開発チームと協力しています。プロジェクトの夜間ビルドとテストを行うビルドマシンのセットアップを提案しました。これは良いことだと理解しているからです。問題は、ここには予算があまりないので、費用を正当化する必要があることです。だから私は知りたい：
- ビルドが壊れていることを示す以外に、正確に何が得られますか？これらのスクリプトによって実行されるテストプロジェクト（slnファイル）をセットアップする必要があります。そうすれば、特定の機能をテストできますか？現時点では、適切な単体テストを作成する時間（または率直に言って、経験）がなかったため、このようなテストが2つあります。
- これにはどのようなハードウェアが必要ですか？
- ビルドが完了してテストされたら、そのビルドをftpサイトに配置するのが一般的な方法ですか、それとも内部アクセスのための他の方法がありますか？アイデアは、このマシンがtheビルドを作成し、私たち全員がそれに行くが、必要であればデバッグビルドを作成できるということです。
- この種のビルドはどのくらいの頻度で行う必要がありますか？
- スペースはどのように管理されますか？ナイトリービルドを作成する場合、すべての古いビルドを保持する必要がありますか、それとも約1週間ほど後にそれらを捨てますか？
- ここにないものはありますか？
これは非常に大きなトピックであることを認識しており、始めたばかりです。ここでこの質問の複製を見つけることができませんでした。もしそこに本があるなら、私はただ手に入れるべきです、私に知らせてください。
編集：私はついに動作するようになりました！ハドソンは完全に素晴らしいです、そして、FxCopは、我々が実装されたと思ったいくつかの機能が実際に不完全であったことを示しています。また、インストーラーの種類を旧式のvdprojからNew Hotness WiXに変更する必要がありました。
基本的に、注意を払っている人のために、コマンドラインからビルドを実行できれば、それをハドソンに入れることができます。コマンドラインからMSBuildを介してビルドを実行することは、ツールを最新の状態に強制するため、それ自体が有用な演習です。
更新： Jenkins は、Hudsonの最新バージョンです。誰もが今ジェンキンスを使用しているはずです。それに応じてリンクを更新します。
Hudson は無料であり、設定が非常に簡単で、VMで簡単に実行できます。
一部は私の古いポストから：
私たちはそれを使用します
- Windowsサービスを展開する
- Webサービスを展開する
- MSTestsを実行し、junitテストと同じ情報を表示します
- 低、中、高のタスクを追跡する
- トレンドグラフの警告とエラー
Hudsonがサポートする組み込みの.netの一部を以下に示します
また、安全な視覚ソースを使用することを禁じています それもサポートしています 。 Hudsonを使用した.netプロジェクトの構築に関するRedsoloの記事 をご覧になることをお勧めします
あなたの質問
[〜＃〜] q [〜＃〜]：どのようなツール/ライセンスが必要ですか？現在、Visual StudioとSmart Assemblyを使用してビルドし、Perforceをソース管理に使用しています。他に何か必要ですか、または自動スクリプトを実行するためのcronジョブに相当するものがありますか？
A：Visual StudioをVM WindowsサーバーOSのパッチを適用した新しいインストールを実行する新しいコピーにインストールしました。 HudsonはWindowsサービスとして自分自身をインストールし、ポート8080で実行し、更新されたコードのコードリポジトリをスキャンする頻度を設定するか、特定の時点でビルドするように指示することができます。時間：すべてブラウザで設定可能。
Q：ビルドが壊れていることを示す以外に、正確に何が得られますか？これらのスクリプトによって実行されるテストプロジェクト（slnファイル）をセットアップする必要があります。そうすれば、特定の機能をテストできますか？現時点では、適切な単体テストを作成する時間（または率直に言って、経験）がなかったため、このようなテストが2つあります。
A：ビルドが初めて失敗したとき、または不安定になったときに電子メールを受け取ります。ビルドは、ユニットテストが失敗した場合、または設定した任意の数の基準を介して不安定とマークされる場合、不安定になります。単体テストまたはビルドが失敗すると、メールで通知され、失敗した場所、理由、および方法が通知されます。私の設定では、次のものが得られます。
- 最後の作業ビルド以降のすべてのコミットのリスト
- それらのコミットのノートをコミット
- コミットで変更されたファイルのリスト
- エラーまたはテストの失敗を示す、ビルド自体からのコンソール出力
Q：これにはどのようなハードウェアが必要ですか？
A：A VMで十分です
Q：ビルドが完了してテストされたら、そのビルドをftpサイトに配置するのが一般的な方法ですか、それとも内部アクセスのための他の方法がありますか？アイデアは、このマシンがビルドを作成し、私たち全員がそれに行くが、必要であればデバッグビルドを作成できるということです。
A：Hudsonは、md5ハッシュを介してIDを付けたり、アップロードしたり、コピーしたり、アーカイブしたりするなど、あなたがやりたいことを何でもすることができます。ビルドアーティファクトの長い実行履歴を提供します。
Q：どのくらいの頻度でこの種のビルドをすべきですか？
A：コードの変更を探してからビルドを実行し、SVNを1時間ごとにポーリングします。 Nightlyは大丈夫ですが、昨日あなたが取り組んだことは、朝に入ったときにあなたの心に新鮮ではないので、多少価値のないIMOです。
Q：スペースはどのように管理されますか？ナイトリービルドを作成する場合、すべての古いビルドを保持する必要がありますか、それとも約1週間ほど後にそれらを捨てますか？
A：それはあなた次第、ビルドアーティファクトを長期保存に移動するか削除するが、テキストファイル/ xmlファイルに保存されているすべてのデータは保持するこれにより、変更ログ、トレンドグラフなどを、ほとんどスペースを消費せずにサーバーに保存できます。また、Hudsonを設定して、後続のビルドのアーティファクトのみを保持することができます
Q：ここに表示されていないものはありますか？
A：いいえ、すぐにハドソンに行きましょう、失望することはありません！
以下のコンボで私たちは幸運に恵まれました。
- Visual Studio（具体的には、MSBuild.exeコマンドラインツールを使用してソリューションファイルを渡します。msbuildスクリプトは不要です）
- NAnt （MSBuildよりも優れたXML構文/タスクライブラリのように。P4src制御操作のオプションもあります）
- CruiseControl.net -ビルドを監視/開始するための組み込みのWebダッシュボード。
CCNetには、ビルドの成功/失敗時に電子メールを送信する通知機能が組み込まれています
正当化：これにより、開発者が手動でビルドする負荷が軽減され、人間のエラーを方程式から取り除くことができます。この効果を定量化することは非常に困難ですが、一度それを行うと二度と戻りません。ソフトウェアをビルドおよびリリースするための反復可能なプロセスを持つことが最も重要です。あなたは彼らが手作業でソフトウェアをビルドし、それが世間に出回っている場所だと確信していますが、ビルド担当者に「おっと、新しいDLLを含めるのを忘れたに違いない！
ハードウェア：できるだけ強力。より多くの電力/メモリ=より速いビルド時間。余裕があれば、どんなに小さなグループであっても、一流のビルドマシンを手に入れることを後悔することはありません。
空き容量：十分なハードディスク容量を確保できます。 NAntスクリプトを作成して、ビルドが開始されるたびに中間ファイルを削除できるため、実際の問題はログ履歴と古いアプリケーションインストーラーを保持することです。ディスク容量を監視し、アラートを送信するソフトウェアがあります。次に、ドライブを手動でクリーンアップします。通常、3〜4か月ごとに行う必要があります。
ビルド通知：これはCCNetに組み込まれていますが、追加のステップとして自動テストを追加する場合は、これを最初からプロジェクトにビルドします。プロジェクトが大きくなると、テストをバックフィットすることは非常に困難です。テストフレームワークに関する情報は山ほどあります（おそらくSOも同様）情報が山ほどあるので、特定のツールの命名は延期します。
以前の職場では、 TeamCity を使用しました。使い方はとても簡単で強力です。制限付きで無料で使用できます。 Dime Casts のチュートリアルもあります。 CruiseControl.NETを使用しなかった理由は、多くの小さなプロジェクトがあり、CC.NETで各プロジェクトを設定するのは非常に苦痛だからです。 TeamCityを強くお勧めします。あなたがオープンソースに向かっているなら要約すると、CC.NETはやや高い学習曲線を持つ大パパです。予算が許せば、TeamCityを使用するか、無料版をチェックしてください。
どうやって？ Carel Lotzの blog をご覧ください。
どうして？私が考えることができるいくつかの理由があります：
- 適切に実装された場合、動作中のビルドは、すべての開発者canがビルドがグリーンのときにマシン上でビルドできることを意味します
- 正常に実装されている場合、動作中のビルドは、いつでもデプロイできる状態であることを意味します
- 正常にビルドされたビルドとは、リリースしたものがソース管理システムにアクセスしたことを意味します。
- 正常にビルドされたビルドは、早期かつ頻繁に統合することを意味し、統合リスクを軽減します。
Continuous Integration に関するMartin Fowlerの記事は、決定的なテキストのままです。ご覧ください！
主な理由は、ビルドが壊れているかテストに失敗したことをできるだけ早く警告することで、開発プロセスのコストを削減することです。
複数の開発者の作業を統合する問題は、チームを成長させる主な危険です。チームが大きくなればなるほど、作業を調整し、互いの変更を混乱させるのを防ぐのが難しくなります。唯一の良い解決策は、完了時に小さな作業単位（「ストーリー」と呼ばれることもある）をチェックインすることにより、「早期かつ頻繁に統合する」ように指示することです。
1日を通して、チェックインするたびにビルドマシンを再構築する必要があります。 Cruise Controlを使用すると、ビルドが壊れると、タスクバーに赤に変わる（さらにはあなたに話しかけることさえできる）アイコンを取得できます。
次に、ソースバージョンにラベルを付けて（一意のビルド番号を付けて）夜間に完全なクリーンビルドを実行し、関係者（製品マネージャー、QA担当者）に公開することを選択できます。これは、バグが報告されたときに、既知のビルド番号に反するようにするためです（非常に重要です）。
理想的には、ビルドをダウンロードできる内部サイトと、前のナイトリービルドを公開するためにクリックできるボタンが必要です。
彼は素晴らしい基盤を築いたので、mjmarshが言ったことを少しだけ構築しようとしています...
- Visual Studio。 MSBuildは正常に動作します。
- NAnt 。
- NantContrib 。これにより、Perforce操作などの追加タスクが提供されます。
- CruiseControl.net 。これも基本的に「ビルドダッシュボード」です。
上記のすべて（VS用に保存）はオープンソースなので、追加のライセンスは必要ありません。
Earwickerが述べたように、早期にビルドし、頻繁にビルドします。何かが壊れていて、成果物を作成できることを知ることは、早い段階で何かをキャッチするのに役立ちます。
NAntにはnunit/nunit2のタスクも含まれているため、実際に単体テストを自動化します。その後、スタイルシートを結果に適用し、CruiseControl.netが提供するフレームワークの助けを借りて、すべてのビルドで読みやすく印刷可能な単体テスト結果を得ることができます。
同じことがndocタスクにも当てはまります。ビルドごとにドキュメントを作成して利用可能にします。
execタスクを使用して、たとえばInstallShieldを使用してWindowsインストーラーを作成するなど、他のコマンドを実行することもできます。
考えは、人間がミスを犯すため、ビルドを可能な限り自動化することです。前もって費やした時間は、将来の節約になります。ビルドプロセスを経てビルドを子守する必要はありません。ビルドのすべてのステップを特定し、各タスクのNAntスクリプトを作成し、ビルドプロセス全体を完全に自動化するまで、NAntスクリプトを1つずつビルドします。また、すべてのビルドを1つの場所に配置します。これは、比較目的に適しています。ビルド380で正常に動作するビルド426で何かが壊れていますか？さて、テストの準備ができた成果物があります-それらをつかんでテストしてください。
- ライセンスは必要ありません。 CruiseControl.netは無料で入手でき、ビルドには.NET SDKのみが必要です。
- ビルドサーバーは、自動化された単体テストがなくても、リリースをビルドするための制御された環境を提供します。これ以上「ジョンは通常彼のマシンでビルドしますが、彼は病気です。何らかの理由で私のマシンでビルドできません」
- 現在、Virtual PCセッションで1つセットアップしています。
- はい。ビルドはアクセス可能な場所にダンプする必要があります。開発ビルドでは、デバッグを有効にする必要があります。リリースビルドではオフにする必要があります。
- あなた次第です。正しく設定されていれば、チェックインごとにオーバーヘッドがほとんどなくなります。ユニットテストを実施している（または計画している）場合、これは素晴らしいアイデアです。
- 必要な限りマイルストーンとリリースを保持します。それ以外は、構築する頻度に依存します。継続的ですか捨てる。毎日？ 1週間分の価値を保ちます。毎週？ 2か月分の価値を保ちます。
プロジェクトが大きくなればなるほど、自動ビルドマシンの利点がわかります。
ビルドの正常性がすべてです。これにより、ビルドで発生させたいあらゆる種類の設定ができるようになります。これらの中で、テスト、静的分析、およびプロファイラーを実行できます。アプリケーションのその部分で最近作業したとき、問題ははるかに高速に処理されます。小さな変更をコミットすると、どこで壊れたのかがほとんどわかります:)
もちろん、これはすべてのチェックインでビルドするようにセットアップすることを前提としています（継続的な統合）。
また、QAと開発者の距離を縮めるのにも役立ちます。プロファイラーや開発チームへのフィードバックを改善するその他の機能とともに、機能テストをセットアップして実行することができます。これは、機能テストがチェックインごとに実行されることを意味するわけではありません（時間がかかる場合があります）が、チーム全体に共通のツールを使用してビルド/テストをセットアップします。私は煙テストを自動化してきたので、私の場合はさらに緊密に協力しています。
理由：10年前、私たちはソフトウェア開発者が何かを分析して、（人間の言語で書かれた）ドキュメントを「承認」し、コードを書き始めました。単体テスト、文字列テスト、そしてシステムテストを実行します。最初にシステム全体が一緒に実行されるとき、時にはドキュメントがサインオフされてから1週間または数か月でした。そのとき初めて、すべてを分析したときに持っていたすべての仮定と誤解を明らかにしました。
継続的インテグレーションとアイデアにより、完全な（最初は非常にシンプルですが）システムをエンドツーエンドで構築できます。時間が経つにつれて、システム機能は直交して構築されます。完全なビルドを行うたびに、システムテストを早期に頻繁に実行しています。これは、バグと仮定をできるだけ早く見つけて修正することを意味します。バグを修正する最も安価な時期です。
方法：方法については、少し前にこのことについてブログに書きました：[ Click Here ]
8を超える投稿では、.NETソリューション用のWindows環境でJenkinsサーバーを設定する方法を段階的に説明しています。