私はJenkinsのように、このようなシステムを維持するのに役立ちます。もちろん詳細は、プロジェクトの構造によって異なりますが、ここで私たちのジェンキンスジョブが何をするか大体です：
- プルコード（我々はGitリポジトリを使用しますが、ジェンキンスのためのMercurialプラグインとしてもあります）
- は、任意のSQLスキーマの変更を実行します私たちの冪等のスクリプトからのテストのDB（我々はハドソン/ジェンキンスの私達の使用を事前にさかのぼるAntスクリプトを使用）
- 実行MSBuildの（別のジェンキンスプラグイン）
- に対してビルドファイルは、私たちの.slnです（またはあなたが使用することができますウェブ.csproj - 引数は若干異なります）
- コマンドライン引数：
- /p：Configuration = Dev/p：プラットフォーム= "任意のCPU"/p：DeployOnBuild = true/p：DeployTarget = Package /p:DeployIisAppPath="dev.mycompany.com/ " V：これは、.zipファイル、.CMDファイル、そしてあなたがあなたのサイトに更新プログラムを展開するために必要なすべてが含まれているいくつかの.xmlファイルを、構築し
- メートル
- キック2その他「場合msdeployオフ"ジェンキンスジョブ、各.NET Webサーバーに1つずつ
- 各.NET Webサーバーは、Jenkinsスレーブ
- NLB経由でバランスの取れた2台のサーバーがあります。
- 各 "msdeploy"ジョブは、ビルドサーバーから.zip/.cmd/.xmlファイルをWebサーバー上の一時的な場所にコピーしてから実行します。 CMDファイル
- .cmdのファイルには、我々はNUnitのテストを実行し、別の仕事を持っていますが、同じように簡単に組み込むことができるあなたのdevのWebサーバーに
をあなたが必要なものすべてを押し出す場合msdeployを実行します主な仕事へのあなたのテスト。 Web .csprojではなく.sln全体を構築する理由の1つは、同じビルド済みコードからユニットテストを実行できることです。
まだビルドサーバーにASP.NET MVC3、.NET 4、およびmsdeployをインストールする必要がありますが、Webサーバーにもほとんど同じファイルが必要になると思います。スケジューリングのための
、あなたは「定期的に構築する」を選択することができたり、「世論調査SCM」ビルドトリガーとして、その後、深夜に毎日実行するのcronに似た構文（0 0 * * *）を使用します。