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