みなさんこんにちは！ Cake（C＃Make）のようなツールについて話したいです。

Cake build

では、Cakeとは何ですか？

Cakeは、ソースコードからのバイナリのコンパイル、ファイルのコピー、フォルダーの作成/消去/削除、アーティファクトのアーカイブ、ナゲットパッケージのパッキング、ユニット実行などのことを行うために、DSLをC＃構文で使用するクロスプラットフォームビルドシステムです-テストなど。 Cakeには、開発されたアドオンシステム（多くの場合nugetにパッケージ化されたC＃クラスのみ）もあります。たくさんの便利な関数が既にCakeに組み込まれていることに注意してください。さらに、ほとんどすべての場合、それらはコミュニティによって作成され、非常にうまく配布されています。

Takeは、 RakeやFakeなどの他の同様のシステムに似た、 依存関係ベースのプログラミングと呼ばれるプログラミングモデルを使用します。このモデルの本質は、プログラムを実行するためにタスクとタスク間の依存関係を定義することです。このモデルの詳細については、 Martin Fowlerをご覧ください。

同様のモデルは、アセンブリプロセスをいくつかのタスクとそれらの間の依存関係として想像させます。この場合、実行は逆の順序で論理的です。実行したいタスクとその依存関係を示し、Cakeは実行できるタスクを決定し（依存関係は許可または欠落）、それらを実行します。

依存関係ベースのプログラミング例

したがって、たとえば、Aを実行したいが、BとCに依存し、BはDに依存します。したがって、Cakeは次の順序でそれらを実行します。

CまたはD
B
A

Cakeのタスクは、通常、アセンブリ/テスト/パッケージング作業の完全な部分です。次のように宣言されています

Task("A") //  .Does(() => { // Task A });

IsDependentOnメソッドを使用して、タスクAがタスクBなどに依存していることを示すには：

 Task("A") //  .IsDependentOn("B") .Does(() => { // Task A });

WithCriteriaメソッドを使用して、タスクを実行する条件と実行しない条件を簡単に設定することもできます。

 Task("B") //  .IsDependentOn("C") .WithCriteria(DateTime.Now.Second % 2 == 0) .Does(() => { // Task A });

一部のタスクがタスクBに依存しており、基準がfalseの場合、タスクBは実行されませんが、実行フローはさらに進んでBのタスクを実行します。

WithCriteriaメソッドのオーバーロードもあります。これは、boolを返す関数をパラメーターとして受け取ります。この場合、式はキューがタスクに到達したときにのみカウントされ、タスクツリーの構築時ではありません。

Cakeは、 load 、 reference 、 tool 、 breakなど、特定のプリプロセッサディレクティブもサポートしています。これらの詳細については、ドキュメントの対応するページをご覧ください。

DevOps時代に自分の手でプロジェクトを収集する人はそれほど多くないと思います。手動アセンブリと比較したアセンブリシステムの利点は明らかです。自動構成プロセスは、手動操作よりも常に優れています。

Cで開発する場合のCakeの利点

非常に多くの選択肢があるので、なぜCakeを使用しますか？ C＃で開発していない場合、ほとんど何もありません。また、開発している場合、別のプログラミング言語を学習して同じコードベース内で動物園を作成する必要がないため、メインプロジェクトが記述されているのと同じ言語でアセンブリスクリプトを記述することは理にかなっています。それが、 Rake（Ruby） 、 Psake（Powershell） 、 Fake（F＃）などのアセンブリシステムが登場し始めた理由です。

確かに、C＃プロジェクトをビルドする方法はCakeだけではありません。オプションとして、純粋なMSBuild、Powershell、Batスクリプト、またはTeamcityやJenkinsなどのCIサーバーを例として使用できますが、すべてに長所と短所があります。

Bat / Bashと同様に、Powershellスクリプトは保守がかなり困難です
C＃ベースのDSLは、MSBuildのXMLベースのDSLの構文が優れています。さらに、Linux / MacでのMSBuildのサポートが登場するのはそれほど前ではありません。
CIサーバーはベンダーロックを実装し、多くの場合「マウスによるプログラミング」を必要とするため、リポジトリ内のコードのバージョンからビルドプロセスのバージョンをバインド解除しますが、一部のCIシステムでは、コードとともにビルドプロセスの説明を含むファイルを保存できます。
CIを使用すると、CIサーバーと同じ方法でローカルにコードを収集できません

ケーキのインストール

次に、タスクを使用してスクリプトを実行する方法について説明します。 Cakeには、すべてを行うブートローダーがあります。手動でダウンロードするか、次のpowershellコマンドを使用してダウンロードできます。

 Invoke-WebRequest http://cakebuild.net/download/bootstrapper/windows -OutFile build.ps1

ダウンロードされたbuild.ps1ファイルは、必要なcake.exeがまだロードされていない場合はダウンロードし、次のコマンドで呼び出すと、cakeスクリプト（デフォルトではbuild.cake ）を実行します。

 Powershell -File ".\build.ps1" -Configuration "Debug"

コマンドライン引数をbuild.ps1に渡すこともできます。これが実行されます。これらは、たとえばアセンブリの構成を通常担当するconfigurationなどの組み込み、または独立して設定できます。この場合、次の2つの方法があります。

ScriptArgsパラメーターの値として渡します。

 Powershell -File ".\build.ps1" -Script "version.cake" -ScriptArgs '--buildNumber="123"'

build.ps1を変更して、渡されたcake.exe引数を転送します。

例

それでは、練習に移りましょう。典型的なnugetパッケージのビルドサイクルは簡単に想像できます。

nuget pack pipeline

dllソースからMSBuildを使用してビルドします
単体テストを実行します
nuspecの説明に従って、すべてをまとめてnugetに入れます
Nugetフィード

ビルドDLL

ソースからソリューションを収集するには、2つのことを行う必要があります。

ソリューションがNuGetRestore関数の使用に依存しているnugetパッケージを復元する
構成パラメーターを渡すことにより、 DotNetBuild関数をcakeに組み込み、デフォルトでソリューションをビルドします。

cake-dslでソリューションを構築するタスクについて説明します。

 var configuration = Argument("configuration", "Debug"); Task("Build") .Does(() => { NuGetRestore("../Solution/Solution.sln"); DotNetBuild("../Solution/Solution.sln", x => x .SetConfiguration(configuration) .SetVerbosity(Verbosity.Minimal) .WithTarget("build") .WithProperty("TreatWarningsAsErrors", "false") ); }); RunTarget("Build");

アセンブリ構成は、それぞれ、デフォルト値の「デバッグ」で引数関数を使用して、コマンドラインによって引数から読み取られます。 RunTarget関数は指定されたタスクを起動し、ケーキスクリプトの正しい動作をすぐに確認できるようにします。

単体テスト

nunit v3.xと互換性のある単体テストを実行するには、 NUnit3関数が必要です。これはCakeに含まれていないため、＃toolプリプロセッサディレクティブを介した接続が必要です。 #toolディレクティブを使用すると、nugetパッケージのツールを接続できます。これを使用します。

 #tool "nuget:?package=NUnit.ConsoleRunner&version=3.6.0"

さらに、タスク自体は非常にシンプルであることがわかりました。もちろん、ビルドタスクに依存することを忘れないでください。

 #tool "nuget:?package=NUnit.ConsoleRunner&version=3.6.0" Task("Tests::Unit") .IsDependentOn("Build") .Does(()=> { NUnit3(@"..\Solution\MyProject.Tests\bin\" + configuration + @"\MyProject.Tests.dll"); }); RunTarget("Tests::Unit");

すべてをナゲットに詰め込みます

アセンブリをnugetにパッケージ化するには、次のnuget仕様を使用します。

 <?xml version="1.0" encoding="utf-8"?> <package xmlns="http://schemas.microsoft.com/packaging/2010/07/nuspec.xsd"> <metadata> <id>Solution</id> <version>1.0.0</version> <title>Test solution for demonstration purposes</title> <description> Test solution for demonstration purposes </description> <authors>Gleb Smagliy</authors> <owners>Gleb Smagliy</owners> <requireLicenseAcceptance>false</requireLicenseAcceptance> <tags></tags> <references> <reference file="MyProject.dll" /> </references> </metadata> <files> <file src=".\MyProject.dll" target="lib\net45"/> <file src=".\MyProject.pdb" target="lib\net45"/> </files> </package>

build.cakeスクリプトを含むフォルダーに配置します。 Packタスクを実行すると、パッケージ化に必要なすべてのアーティファクトが「.. \。Artefacts」フォルダーに転送されます。これを行うには、 EnsureDirectoryExists関数を使用して存在することを確認し（存在しない場合は作成し）、Cakeに組み込まれているCleanDirectory関数を使用して削除します。ファイルコピー機能の助けを借りて、必要なdllとpdbをarefactoryフォルダーに移動します。

デフォルトでは、アセンブルされたnupkgは現在のフォルダーにあるため、フォルダー ".. \ package"をOutputDirectoryとして指定し 、これも作成およびクリーンアップします。

 Task("Pack") .IsDependentOn("Tests::Unit") .Does(()=> { var packageDir = @"..\package"; var artefactsDir = @"..\.artefacts"; MoveFiles("*.nupkg", packageDir); EnsureDirectoryExists(packageDir); CleanDirectory(packageDir); EnsureDirectoryExists(artefactsDir); CleanDirectory(artefactsDir); CopyFiles(@"..\Solution\MyProject\bin\" + configuration + @"\*.dll", artefactsDir); CopyFiles(@"..\Solution\MyProject\bin\" + configuration + @"\*.pdb", artefactsDir); CopyFileToDirectory(@".\Solution.nuspec", artefactsDir); NuGetPack(new FilePath(artefactsDir + @"\Solution.nuspec"), new NuGetPackSettings { OutputDirectory = packageDir }); }); RunTarget("Pack");

公開する

パッケージを公開するには、 NuGetPush関数を使用します 。これは、nupkgファイルへのパスと、設定：nugetフィードへのリンクとAPIキーを使用します。もちろん、APIキーをリポジトリに保存するのではなく、 Argument関数を使用して外部に再度渡します。 nupkgの場合は、 パッケージディレクトリ内の最初のファイルを取得し、 GetFilesを使用してマスクを一致させます。パッケージを作成する前にディレクトリが以前にクリーンアップされているため、これが可能です。そのため、公開タスクは次のdslで記述されます。

 var nugetApiKey = Argument("NugetApiKey", ""); Task("Publish") .IsDependentOn("Pack") .Does(()=> { NuGetPush(GetFiles(@"..\package\*.nupkg").First(), new NuGetPushSettings { Source = "https://www.nuget.org/api/v2", ApiKey = nugetApiKey }); }); RunTarget("Publish");

あなたの人生を簡素化

cakeスクリプトをデバッグしている間、そして単にnugetパッケージをデバッグするために、毎回リモートフィードに公開することはできません。ここで、 調査したWithCriteria関数が役立ちます。このフラグの値によってパッケージをリモートフィードに配置するかどうかを決定するために、パラメータ（デフォルトではfalseに設定）でスクリプトにPublishRemotelyフラグを渡します。ただし、 RunTarget関数で指定されたタスクをスキップすると、cakeはスクリプトを実行しません。したがって、 Publishに依存する架空の空のタスクBuildAndPublishを開始します。

 Task("BuildAndPublish") .IsDependentOn("Publish") .Does(()=> { }); RunTarget("BuildAndPublish");

そして、公開タスクに条件を追加します。

 var nugetApiKey = Argument("NugetApiKey", ""); var publishRemotely = Argument("PublishRemotely", false); Task("Publish") .IsDependentOn("Pack") .WithCriteria(publishRemotely) .Does(()=> { NuGetPush(GetFiles(@"..\package\*.nupkg").First(), new NuGetPushSettings { Source = "https://www.nuget.org/api/v2", ApiKey = nugetApiKey }); });

nugetパッケージを構築および公開するためのスクリプトはほとんど準備ができており、すべてのタスクを一緒に結合するだけです。コードの最終バージョンはgithubリポジトリにあります。

おわりに

ケーキの最も簡単な使用例を見ました。これにより、スラックとの統合、テストによるコードカバレッジの監視などが可能になります。豊富なアドオンシステム、活発なコミュニティ、および非常に優れたドキュメントを備えたCakeは、C＃コードを構築するためのCIシステムおよびMSBuildの代替として非常に優れています。

Cakeを使用してC＃コードをビルドする