144

私は、C# プロジェクトで小規模 (4 人) の開発チームと協力しています。プロジェクトの夜間のビルドとテストを行うビルド マシンをセットアップすることを提案しました。これは良いことだと理解しているからです。問題は、ここには十分な予算がないことです。そのため、その費用を権力者に正当化する必要があります。だから私は知りたい：

  • どのようなツールやライセンスが必要ですか? 現在、Visual Studio と Smart Assembly を使用してビルドし、Perforce をソース管理に使用しています。他に何か必要ですか、それとも自動化されたスクリプトを実行するための cron ジョブに相当するものはありますか?
  • What, exactly, will this get me, other than an indication of a broken build? Should I set up test projects in this solution (sln file) that will be run by these scripts, so I can have particular functions tested? We have, at the moment, two such tests, because we haven't had the time (or frankly, the experience) to make good unit tests.
  • What kind of hardware will I need for this?
  • Once a build has been finished and tested, is it a common practice to put that build up on an ftp site or have some other way for internal access? The idea is that this machine makes the build, and we all go to it, but can make debug builds if we have to.
  • How often should we make this kind of build?
  • スペースはどのように管理されていますか? ナイトリー ビルドを作成する場合、古いビルドをすべて維持する必要がありますか? それとも、約 1 週間後にそれらを破棄し始める必要がありますか?
  • ここに表示されていないものは他にありますか?

    これは非常に大きなトピックであることを認識しており、私はまだ始めたばかりです。ここでこの質問の重複を見つけることができませんでした。入手すべき本がそこにある場合は、お知らせください.

    編集：私はついにそれを働かせました！Hudson は完全に素晴らしいものであり、FxCop は、実装されていると思っていたいくつかの機能が実際には不完全であることを示しています。また、インストーラーの種類を Old-And-Busted vdproj から New Hotness WiX に変更する必要がありました。

    Basically, for those who are paying attention, if you can run your build from the command line, then you can put it into hudson. Making the build run from the command line via MSBuild is a useful exercise in itself, because it forces your tools to be current.

    • 4

    9 に答える 9

    26

    次のコンボで大成功を収めました。

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

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

    正当な理由: これにより、開発者が手作業でビルドを行う負担が軽減され、人的エラーを方程式から取り除くために多くのことが行われます。この効果を定量化することは非常に困難ですが、一度実行すると元には戻せません。ソフトウェアをビルドしてリリースするための反復可能なプロセスを持つことが最も重要です。手作業でソフトウェアをビルドし、それが世に出て、ビルド担当者に「おっと、その新しい DLL を含めるのを忘れていたに違いない!」と言われたことがあると思います。

    ハードウェア: 可能な限り強力。より多くの電力/メモリ = ビルド時間の短縮。余裕があれば、グループがどんなに小さくても、一流のビルドマシンを手に入れたことを後悔することはありません.

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

    ビルド通知について: これは CCNet に組み込まれていますが、追加のステップとして自動テストを追加する場合は、最初からこれをプロジェクトに組み込みます。プロジェクトが大きくなると、テストをバックフィットするのは非常に困難です。テスト フレームワークに関する情報は山ほどあります (おそらく、SO に関する情報も山ほどあります)。そのため、特定のツールに名前を付けるのは控えます。

    于 2009-03-05T19:09:21.683 に答える
    11

    以前の職場ではTeamCityを使用していました。非常に使いやすく強力です。一部制限付きで無料で利用できます。Dime Castsに関するチュートリアルもあります。CruiseControl.NET を使用しなかった理由は、多数の小さなプロジェクトがあり、それぞれを CC.NET でセットアップするのが非常に面倒だったからです。TeamCity を強くお勧めします。要約すると、オープン ソースに関心がある場合、CC.NET は学習曲線がわずかに高いおじいちゃんです。予算が許せば、間違いなく TeamCity を使用するか、無料版をチェックしてください。

    于 2009-03-06T08:08:25.447 に答える
    10

    どのように？Carel Lotz のブログをご覧ください。

    なんで？私が考えることができるいくつかの理由があります：

    • 適切に実装された場合、動作するビルドは、ビルドがグリーンのときにすべての開発者が自分のマシンでビルドできることを意味します
    • 適切に実装された作業ビルドは、いつでも展開する準備ができていることを意味します
    • 適切に実装されたビルドが機能するということは、リリースしたものがソース管理システムに移動したことを意味します。
    • 適切に実装された作業ビルドは、早期に頻繁に統合し、統合リスクを軽減することを意味します。

    継続的インテグレーションに関する Martin Fowler の記事は、依然として決定的なテキストです。それを見てください！

    于 2009-03-05T19:34:45.930 に答える
    5

    彼は素晴らしい基盤を築いたので、mjmarshが言ったことを少し構築しようとしています...

    • VisualStudio。MSBuildは正常に動作します。
    • NAnt。
    • NantContrib。これにより、PERFORCE操作などの追加タスクが提供されます。
    • CruiseControl.net。これも基本的には「ビルドダッシュボード」です。

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

    Earwickerが述べたように、早期にビルドし、頻繁にビルドします。何かが壊れたことを知っていて、成果物を作成できることは、早い段階で物を捕まえるのに役立ちます。

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

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

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

    人間は間違いを犯すので、アイデアは可能な限りビルドを自動化することです。前もって費やした時間は、将来的に節約された時間です。ビルドプロセスを実行することで、ビルドをベビーシッターする必要はありません。ビルドのすべてのステップを特定し、タスクごとにNAntスクリプトを作成し、ビルドプロセス全体が完全に自動化されるまで、NAntスクリプトを1つずつビルドします。また、すべてのビルドを1つの場所に配置します。これは、比較の目的に適しています。ビルド380で正常に機能したビルド426で何かが壊れていますか？さて、テストの準備ができている成果物があります-それらをつかんでテストしてください。

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

    プロジェクトが大きくなるほど、自動ビルドマシンのメリットがわかります。

    于 2009-03-05T19:28:40.810 に答える
    1

    理由: 10 年前、私たちはソフトウェア開発者として何かを n 次まで分析していましたが、(人間の言語で書かれた) ドキュメントを「承認」してからコードを書き始めました。単体テスト、文字列テストを行ってから、システム テストを行います。システム全体を初めて一緒に実行するときで、ドキュメントが承認されてから 1 週間または数か月かかることもあります。すべてを分析したときに持っていたすべての仮定と誤解が明らかになったのは、そのときだけでした。

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

    方法: 方法については、少し前にブログに書きました: [ここをクリック]

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

    于 2012-11-01T01:31:33.210 に答える