C＃ビルドマシンをセットアップする方法と理由 [閉まっている]

私はC＃プロジェクトで小さな（4人の）開発チームと協力しています。これは良いことだと理解しているので、プロジェクトの夜間ビルドとテストを行うビルドマシンのセットアップを提案しました。困ったことに、ここには予算があまりないので、その力への出費を正当化しなければなりません。だから私は知りたい：

更新：JenkinsはHudsonの最新バージョンです。誰もが今ジェンキンスを使用する必要があります。それに応じてリンクを更新します。

Hudsonは無料で、設定が非常に簡単で、VMで簡単に実行できます。

一部は私の古い投稿から：

私たちはそれを使用します

• Windowsサービスを展開する
• Webサービスをデプロイする
• MSTestを実行し、junitテストと同じくらい多くの情報を表示する
• 低、中、高のタスクを追跡する
• トレンドグラフの警告とエラー

Hudsonがサポートする組み込み.netの一部を以下に示します

• MSBuild
• NAnt
• MSTest
• Nunit
• Team Foundation Server
• fxcop
• スタイルコップ
• コンパイラの警告
• コードタスク

また、ビジュアルソースセーフを使用することを禁じています。これもサポートしています。Hudsonを使用した.netプロジェクトの構築に関するRedsoloの記事をご覧になることをお勧めします

あなたの質問

• Q：どのようなツール/ライセンスが必要ですか？現在、ビルドにはVisual StudioとSmart Assembly、ソース管理にはPerforceを使用しています。他に何か必要ですか、または自動化されたスクリプトを実行するためのcronジョブに相当するものはありますか？

• A： Visual Studioを、パッチが適用された新しいWindowsサーバーOSのインストールを実行しているVMの新しいコピーにインストールしました。したがって、それを処理するにはライセンスが必要です。Hudsonはそれ自体をWindowsサービスとしてインストールし、ポート8080で実行します。更新されたコードがないかコードリポジトリをスキャンする頻度を設定するか、特定の時間にビルドするように指示できます。すべてブラウザで設定可能。

• Q：正確には、ビルドが壊れていることを示す以外に、これで何が得られますか？特定の機能をテストできるように、これらのスクリプトによって実行されるこのソリューション（slnファイル）にテストプロジェクトを設定する必要がありますか？現時点では、このようなテストは2つあります。これは、優れた単体テストを作成する時間（または率直に言って、経験）がないためです。

  A：ビルドが初めて失敗したとき、または不安定になったときにメールが届きます。ユニットテストが失敗した場合、ビルドは不安定になります。または、設定した任意の数の基準によってビルドを不安定とマークすることができます。単体テストまたはビルドが失敗すると、メールで通知され、どこで、なぜ、どのように失敗したかが通知されます。私の設定では、次のようになります。

  • 最後の作業ビルド以降のすべてのコミットのリスト
  • それらのコミットのメモをコミットする
  • コミットで変更されたファイルのリスト
  • エラーまたはテストの失敗を示す、ビルド自体からのコンソール出力

• Q：これにはどのようなハードウェアが必要ですか？

  A： VMで十分です

• Q：ビルドが完了してテストされたら、そのビルドをftpサイトに配置するのが一般的な方法ですか、それとも内部アクセスに他の方法がありますか？アイデアは、このマシンがビルドを作成し、私たち全員がそれに行くが、必要に応じてデバッグビルドを作成できるということです。

  A： Hudsonは、md5ハッシュを介したIDのアップロード、アップロード、コピー、アーカイブなどを含め、好きなように実行できます。これにより、ビルドアーティファクトの長い実行履歴が自動的に提供されます。

• Q：この種類のビルドはどのくらいの頻度で行う必要がありますか？

  A： 1時間ごとにSVNにポーリングして、コードの変更を探し、ビルドを実行します。毎晩は大丈夫ですが、昨日取り組んだことは、朝に入ると心の中で新鮮にならないので、やや価値のないIMOです。

• Q： スペースはどのように管理されますか？夜間ビルドを作成する場合、古いビルドをすべて維持する必要がありますか、それとも約1週間後からそれらを破棄し始める必要がありますか？

  A：それはあなた次第です。私はビルドアーティファクトを長期保存に移動するか削除しますが、テキストファイルやxmlファイルに保存されているすべてのデータを保持しているため、変更ログやトレンドグラフを保存できます。サーバー上の不規則な少しのスペースが消費されるなど。また、Hudsonを設定して、後続のビルドのアーティファクトのみを保持することもできます。

• Q：ここに表示されていない他に何かありますか？

  A：いいえ、ハドソンを今すぐ入手してください。あなたは失望することはありません！

私たちは次のコンボで大成功を収めました：

1. Visual Studio（具体的には、MSBuild.exeコマンドラインツールを使用してソリューションファイルを渡す。msbuildスクリプトが不要になります）
2. NAnt（XML構文/タスクライブラリのようにMSBuildより優れています。P4srcコントロール操作のオプションもあります）
3. CruiseControl.net-ビルドを監視/開始するための組み込みのWebダッシュボード。

CCNetには、ビルドの成功/失敗時にメールを送信する通知機能が組み込まれています

正当化について：これは、手動ビルドを行う開発者の負担を軽減し、人的エラーを方程式から取り除くために多くのことを行います。この効果を定量化することは非常に困難ですが、一度行うと二度と戻ることはありません。ソフトウェアを構築してリリースするための反復可能なプロセスを用意することが最も重要です。あなたが彼らがソフトウェアを手作業でビルドし、それが自然に出回る場所であったと私は確信しています。

ハードウェア上：可能な限り強力。より多くの電力/メモリ=より速いビルド時間。あなたがそれを買う余裕があるなら、どんなに小さなグループであっても、一流のビルドマシンを手に入れることを後悔することは決してないでしょう。

空き容量：十分なハードディスク容量を確保するのに役立ちます。NAntスクリプトを作成して、ビルドが開始するたびに中間ファイルを削除できるため、実際の問題はログ履歴と古いアプリケーションインストーラーを保持することです。ディスク容量を監視してアラートを送信するソフトウェアがあります。次に、ドライブを手動でクリーンアップします。通常、3〜4か月ごとに実行する必要があります。

ビルド通知：これはCCNetに組み込まれていますが、追加のステップとして自動テストを追加する場合は、最初からプロジェクトに組み込みます。プロジェクトが大きくなると、適合テストをバックアップすることは非常に困難です。テストフレームワークに関する情報はたくさんあります（おそらくSOについてもたくさんの情報があります）ので、特定のツールの命名については延期します。

以前の職場ではTeamCityを使用しました。使い方はとても簡単で強力です。制限付きで無料でご利用いただけます。ダイムキャストに関するチュートリアルもあります。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。これも基本的には「ビルドダッシュボード」です。

上記すべて（VS用に保存）はオープンソースであるため、追加のライセンスを検討する必要はありません。

Earwickerが述べたように、早期に構築し、頻繁に構築します。何かが壊れていて、成果物を作成できることを知ることは、早い段階で何かをキャッチするのに役立ちます。

NAntにはnunit / nunit2のタスクも含まれているため、実際にユニットテストを自動化できます。その後、スタイルシートを結果に適用し、CruiseControl.netによって提供されるフレームワークを利用して、すべてのビルドについて、読みやすく印刷可能な単体テスト結果を得ることができます。

同じことがndocタスクにも当てはまります。すべてのビルドで、ドキュメントを作成して利用できるようにします。

execタスクを使用して、他のコマンドを実行することもできます。たとえば、InstallShieldを使用してWindowsインストーラーを作成します。

人間は間違いを犯すので、アイデアはビルドをできるだけ自動化することです。事前に費やされた時間は、道のりで節約された時間です。人々は、ビルドプロセスを実行することで、ビルドの面倒を見る必要はありません。ビルドのすべてのステップを特定し、タスクごとにNAntスクリプトを作成し、ビルドプロセス全体を完全に自動化するまで、NAntスクリプトを1つずつビルドします。また、すべてのビルドを1か所に配置するので、比較に役立ちます。ビルド380で問題なく動作したビルド426に問題がありますか？さて、テストの準備ができている成果物があります-それらを取得してテストしてください。

• ライセンスは必要ありません。CruiseControl.netは無料で利用でき、.NET SDKをビルドするだけで済みます。
• ビルドサーバーは、自動化された単体テストがなくても、リリースをビルドするための制御された環境を提供します。「ジョンは通常彼のマシンでビルドしますが、彼は病気です。何らかの理由で自分のマシンでビルドできません。」
• 現在、Virtual PCセッションでセットアップしています。
• はい。ビルドはアクセス可能な場所にダンプする必要があります。開発ビルドではデバッグをオンにする必要があります。リリースビルドはそれをオフにする必要があります。
• 頻度はあなた次第です。正しく設定されていれば、各チェックイン後にオーバーヘッドをほとんど発生させずにビルドできます。単体テストを実施している（または実施する予定がある）場合、これは優れたアイデアです。
• 必要な限り、マイルストーンとリリースを保持します。他に何かはあなたが構築する頻度に依存します：継続的に？捨てる。毎日？1週間分の価値を保ちます。毎週？2か月分の価値を保ちます。

プロジェクトが大きくなればなるほど、自動ビルドマシンの利点が多く見えます。

それはすべてビルドの状態に関するものです。これによって得られるのは、ビルドで実行したいあらゆる種類の事柄をセットアップできることです。これらの中で、テスト、静的分析、プロファイラーを実行できます。アプリケーションのその部分に最近取り組んだとき、問題ははるかに速く処理されます。小さな変更をコミットした場合、それはどこでそれを壊したかをほとんど教えてくれます:)

もちろんこれは、すべてのチェックイン（継続的インテグレーション）でビルドするようにセットアップすることを前提としています。

また、QAとDevを近づけるのにも役立ちます。プロファイラーや開発チームへのフィードバックを改善するその他の機能とともに、それを使用して機能テストをセットアップできるので。これは、すべてのチェックインで機能テストが実行されることを意味するわけではありませんが（時間がかかる場合があります）、チーム全体に共通のツールを使用してビルド/テストを設定します。私は煙のテストを自動化しているので、私の場合はさらに緊密に協力しています。

理由：10年前、ソフトウェア開発者は何かをn度まで分析するために使用し、ドキュメント（人間の言語で書かれた）を「サインオフ」し、コードの作成を開始しました。ユニットテスト、文字列テスト、次にシステムテストを実行します。システム全体が初めて一緒に実行されるとき、ドキュメントがサインオフされてから数週間または数か月かかる場合があります。すべてを分析したときに私たちが持っていたすべての仮定と誤解を明らかにするのはそのときだけでした。

継続的な統合とアイデアにより、完全な（ただし、最初は非常に単純な）システムをエンドツーエンドで構築することができます。時間の経過とともに、システム機能は直交して構築されます。完全なビルドを行うたびに、システムテストを早期かつ頻繁に行っています。これは、バグや想定をできるだけ早く修正して修正できる時期であるときに、バグや想定を見つけて修正することを意味します。

方法：方法については、少し前にブログで説明しました：[ ここをクリック ]

8つ以上の投稿では、.NETソリューション用のWindows環境でJenkinsサーバーを設定する方法を段階的に説明しています。