最初に利用できたもの
会社のメインプラットフォームである大規模なエンタープライズシステム。 構造には、システムのコアとさまざまなタスク用のプラグインのセットが含まれます。 プラグインは互いに独立して開発されており、共有ライブラリの変更と拡張が必要です。
システムの開発と分岐により、共通のプロジェクトですべてのプラグインを見つけると、コードのサポートが難しくなりました。 リポジトリには常にいくつかのブランチがあり、リリースの準備と変更のマージに大きな困難をもたらしました。
したがって、インフラストラクチャを作成し、さまざまなプラグインのプロジェクトのアセンブリを自動化するスクリプトを構成するために、意思決定が行われました。
問題を解決するときに、次のツールが使用されました：NuGet、TeamCity、NAnt、Visual Studio 2010、SlowCheetah。
なぜそれが必要ですか
Joel Testを使用して、作業を評価します。 私の投稿で説明されているアクションは、ポイント2と3をカバーしています。
問題解決
徐々に、プロジェクトはすべてのプラグインを個別のプロジェクトに分離するように進化し、VCS（バージョン管理システム）の各プロジェクトのリポジトリを作成しました。 プロジェクトは、ビルドサーバー（TeamCity）にインストールされたハードバージョンを受け取りました。 アセンブリファイルのバージョンは、機能のメジャーバージョンとマイナーバージョン、VCSのリビジョン番号、ビルド構成の開始試行回数の4桁で構成されていました。
[assembly: AssemblyVersion("1.0")] [assembly: AssemblyFileVersion("1.0.0.0")]
メインモジュールは、NuGetを使用していくつかのパッケージの機能のために結合されました。 パッケージの構成はnuspecファイルによって記述され、リリースブランチへのコミットごとに新しいバージョンでパッケージが再構築されました（トリガーはTeamCityで機能しました）。 NuGetパッケージはビルドサーバーに保存され、共有ディレクトリを介してローカルネットワーク経由でアクセスできました。
nuspecファイルのサンプル
<?xml version="1.0"?> <package xmlns="http://schemas.microsoft.com/packaging/2010/07/nuspec.xsd"> <metadata> <id>Core</id> <version>1.0.0.0</version> <authors>DefaultCompanyName</authors> <requireLicenseAcceptance>false</requireLicenseAcceptance> <description> </description> <frameworkAssemblies> <frameworkAssembly assemblyName="System.Configuration" targetFramework="net35" /> <frameworkAssembly assemblyName="System.Core" targetFramework="net35"/> <frameworkAssembly assemblyName="System.Drawing" targetFramework="net35"/> <frameworkAssembly assemblyName="System.Runtime.Serialization" targetFramework="net35"/> <frameworkAssembly assemblyName="System.ServiceModel" targetFramework="net35"/> <frameworkAssembly assemblyName="System.Windows.Forms" targetFramework="net35"/> <frameworkAssembly assemblyName="System.Xml" targetFramework="net35"/> </frameworkAssemblies> </metadata> <files> <file src="core\bin\Release\*.dll" target="lib" /> </files> </package>
メインのビルドツールはNAntとMSBuildでした。 Csprojプロジェクトは、構成を変換し、依存ライブラリをダウンロードするための追加の指示で拡張されました。
プロジェクトを組み立てるときに、依存関係が決定されました。 NuGet関数Enable-PackageRestore（バージョン1.6以降はVisual Studioの拡張機能に含まれています）を使用すると、コンパイル中に必要なバージョンのNugetパッケージを自動的に検索してダウンロードできます。 使用済みライブラリのバイナリファイルをVCSに保存する必要はありません。 ビルドサーバーでプロジェクトをビルドするときに、同様のシナリオが実行されました。 NuBuildユーティリティ自体をMSBuildのターゲットセットと共にプロジェクトリポジトリに格納するだけで十分です。
プロジェクトファイルの変更
<Project ToolsVersion="4.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003"> ... <SolutionDir Condition="$(SolutionDir) == '' Or $(SolutionDir) == '*Undefined*'">..\</SolutionDir> <RestorePackages>true</RestorePackages> ... <SlowCheetahTargets Condition=" '$(SlowCheetahTargets)'=='' ">..\.slowCheetah\SlowCheetah.Transforms.targets</SlowCheetahTargets> ... <Import Project="$(SolutionDir)\.nuget\NuGet.targets" /> <Import Project="$(SlowCheetahTargets)" Condition="Exists('$(SlowCheetahTargets)')" /> </Project>
各プラグインは、構成ファイルに要素を追加または変更してシステム構成を変更する必要がありました。 xmlファイルを変換するSlowCheetahプロジェクトを使用しました。 構成ファイルは、ターゲット=「コンテンツ」でヌゲットパッケージに含まれ、プロジェクトファイルとして追加されました。 変換により2つのファイルが追加されました。 たとえば、Client.configファイルに対してClient.Debug.configファイルとClient.Release.configファイルが作成されます。 プロジェクトの構築に使用される現在の構成に応じて、この変換またはその変換が適用されます。
組み立てられたプロジェクトが、zipファイルとしてWebインターフェースを介してTeamCityからダウンロードできるように、成果物を構成できます。
おわりに
その結果、アプリケーションのアセンブリを自動化するデバッグメカニズムが得られます。 主な利点は、迅速な組み立てと
参照資料
ヌジェ
Teamcity
Nnt
スローチーター