TFS 2012のF＃/ C＃でアセンブリスクリプトを使用します

TFSでいわゆるビルドプロセステンプレートを変更および/または拡張する必要があるときに、悪い言葉でマイクロソフトを思い出すのは私だけではないと思います。 カットの下には、XamlからF＃/ C＃のスクリプトに切り替えた方法の話があります。 FakeをTFSに統合しようとした方法ですが、最終的には独自のソリューションであるAnFakeを取得しました 。



この記事は、CIソリューションとしてTFSを使用しているが、そのアセンブリプロセステンプレートに熱心ではない人に役立ちます。



プロジェクトの開発中（実際には、会社の実際の製品用のバイナリ供給モジュールです）、単体テストをコンパイルして実行するよりも少し複雑なCIプロセスが必要であることがわかりました。



これは、「理想的な」プロセスが私たちの目に見えるものです。



定期的な組み立て：

• 単体テストのコンパイルと実行。
• テストサンプルの準備（サンプルは出荷の一部であり、テストの後続段階で製品によって使用されます。準備は、さまざまな場所からファイルを収集し、特定のフォルダー構造にソートしてパックすることです）。
• パフォーマンステストの実行。 結果の保存（グラフを作成できるように）; 偏差が平均二乗を超えた場合に警告を生成します。
• falseおよびtrue応答のテストを実行します。 レポートおよび/またはさらなる研究のために結果を保存する。

配送：

• TFSからのバグとタスクに関するリリースノートの生成。
• ポータルでのリリースノートの公開。
• バグおよびタスクのアセンブリ番号の自動登録。
• 準備された配信アーカイブを特定の場所にアップロードして、製品で将来使用できるようにします。

弊社のワークフローは、バグやタスクの追跡など、完全にTFS上に構築されています。 バージョン管理と継続的な統合。 TFSのCIアセンブリは、ビルドプロセステンプレートを使用して定義されます。 「理想」を実現するために私たちが最初に試みたのは、プロセステンプレートを自分用にカスタマイズすることでした。そして、多くの困難に直面しました。



1.モジュールの開発（特に、テストサンプルの準備）に伴い、アセンブリロジックの一部が変更されます。 モジュールの他のソースコードとともに、このロジックをバージョン管理システムに保持することが望ましいです。 ただし、TFS 2012/2013のプロセステンプレートは個別に保存され、バージョン管理されません（はい、VCSにありますが、常に最新バージョンのみが使用されます）。 なぜこれが問題なのですか？ 少なくとも2つのブランチがあります：開発と安定（理論的には、修正プログラムを作成する必要がある場合、リリースブランチがまだ発生する可能性があります）、少なくとも、いくつかのアセンブリ手順はそれらで異なります。 1つのテンプレートですべてのブランチを収集することはできません。



可能な解決策：

• テンプレートを手動でバージョン管理し、テンプレートファイルの名前にバージョン番号を追加します。 この場合、ブランチをマージするとき、テンプレートのマージを忘れないでください。 突然、テンプレートの編集に加えて、独自のアクティビティが必要になった場合、これらのアクティビティを含むdllに擬似バージョン管理も適用する必要があります。
• 変更するロジックをスクリプトに取り込み、テンプレートからこのスクリプトを呼び出します。 スクリプトは、モジュールの残りのソースコードと共に保存されます。

スクリプトを選択しました。 最初の段階で-通常のバットファイル。



2.スクリプトを使用すると、別の問題が発生しました-ロギングの情報量が急激に減少しました。 メッセージは単にコンソールに書き込まれ、レベルはありません。警告と診断を区別することはできません。 エラーを強調表示するには、メッセージをstderrに書き込む必要があります。 ただし、TFSがstderrから読み取る各行は、個別のエラーとして認識されます。 したがって、たとえば、TFSでフォーマットされた3行のエラーメッセージは、3つの個別のエラーとして表示されます。 「きちんと」ではありませんが、あなたは生きることができます。



3.スクリプトが成長し始めました。 サンプル準備ステップに加えて、すぐにパフォーマンステストとFP / TPテストが行​​われました。 なぜそう 実行中のテストはテンプレート内にあるように思われます。 実際、これらのテストはツールによって実行されます。ツールもモジュールの一部であり、それに応じて開発されているため、起動方法も変わります。 テンプレートに残しておくと、パラグラフ1で既に説明した問題があります。



もっともっと。 スクリプトから現在のアセンブリのプロパティ（ブランチの名前、バージョン番号など）にアクセスしたいという要望が成熟し始め、他のアセンブリに連絡してパイプラインを整理しました。



この段階で、スクリプトは単なるバットファイルよりも強力であることが明らかになりました。 プロセステンプレートをいじるのはそれほど便利ではないことを考えると、すべてのロジックをスクリプトに転送し、テンプレートをシェルとしてのみ使用して、ソースをポンプアウトし、スクリプトに制御を転送することが望まれました。



スクリプトの候補は、 PSake 、 Rake、およびFakeです。 簡単な分析の後、PowerShell構文のためにPSakeは削除されました。 熊手-なぜなら 私たちのチームの誰もRubyに慣れていませんでした。 偽物のままでした。 公平に言えば、その時点ではチームのF＃を誰も知らなかったと言わなければなりませんが、F＃はそのままVisual Studioでサポートされていたので、私たちはそれで解決しました。



残念ながら、FakeはTFSとは友達ではありません。 しかし、私たちはプログラマーなどではありませんか？！ 自分でねじ込み。 問題1と3は解決されたと言えます。 ただし、問題2は次のように悪化しています。 アセンブリ全体がスクリプトになったため、Visual Studioに表示される結果は気のめいるように見えました-警告は表示されませんでした（コンパイラからのものを含む）。 実行されたステージは表示されません。 間違いはひどい「履物」によって示されます。 彼らはFakeの拡張機能を作成してこの問題を解決しようとしましたが、Fakeには構造化出力をTFSにリダイレクトする単一のログポイントがありませんでした。 途中で、さらにいくつかの不満が生じました（詳細については、 こちらをご覧ください ）。



それにもかかわらず、私は、本格的なプログラミング言語を使用してアセンブリを記述するというアイデアが好きでした。 最終的に、私は余暇に自分のパフォーマンスでフェイクのアイデアを実現することにしました。 重点が置かれたのは：

• 拡張性（たとえば、アセンブリに関するプラグインhtmlレポート、またはデータベースでのテスト結果の公開など）。
• さまざまな外部システムとの統合（キューの最初はTFSでした）。
• 読みやすく理解しやすいログおよびエラー出力。

さらに、F＃スクリプトを理解しようとする最初の試みを思い出して、「C＃でもスクリプトを記述できるといい」と考え、この要件を作業範囲に含めました。 はい、アセンブリスクリプトをC＃で記述できますが、残念ながら、この場合IntelliSenseは機能しません。スタジオはC＃がスクリプトになり得ることを認識していません。



その結果、非常にまともなツール（AnFake = Another F＃Makeと呼ばれます）が作成され、TFSと「戦っている」すべての人にとって有用になります。 それがどのようなもので何ができるかを見てみましょう（現在、AnFakeは主にTFS向けに設計されているため、TFSのコンテキストでさらに議論します）。



TFSバージョン管理システムにあるDemoと呼ばれるソリューションがあるとします。

$/TeamProject/Demo /dev /Demo.App /Demo.Lib /Demo.Lib.Test Demo.sln
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

また、単一のマッピングでワークスペース「Demo.dev」を構成しました。

 $/TeamProject/Demo/dev: C:\Projects\Demo.dev
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

（以下、「ブランチごとに1つのワークスペース」スキームが使用されると想定されています）



Visual StudioでC：\ Projects \ Demo.dev \ Demo.slnを開きます。 AnFakeをNuGetパッケージとしてインストールします。

 PM> Install-Package AnFake
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

パッケージをインストールすると、ソリューションのルートフォルダーにいくつかのファイルが作成されます。

• build.fsx-MSBuildの呼び出しとテストの実行を含む基本的なビルドスクリプト。
• anf.cmd-AnFakeを呼び出すためのエイリアス（./packages/AnFake.xyz/bin/AnFake.exeを毎回書き込まない）;
• .workspace-現在のソリューションがダウンロードされたワークスペースからのマッピングの説明を含むテキストファイル。
• .nu​​get \ NuGet.config-[そうでない場合のみ作成]には、VCSでバイナリパッケージファイルがコミットされないようにするdisableSourceControlIntegrationオプションが含まれています。

（ところで、インストールスクリプトはAnFakeのF＃スクリプトでもあります）



基本的なbuild.fsxスクリプトは次のとおりです。

 Tfs.PlugIn() let out = ~~".out" let productOut = out / "product" let testsOut = out / "tests" let tests = !!"*/*.Test.csproj" let product = !!"*/*.csproj" - tests "Clean" => (fun _ -> let obj = !!!"*/obj" let bin = !!!"*/bin" Folders.Clean obj Folders.Clean bin Folders.Clean out ) "Compile" => (fun _ -> MsBuild.BuildRelease(product, productOut) MsBuild.BuildRelease(tests, testsOut) ) "Test.Unit" => (fun _ -> VsTest.Run(testsOut % "*.Test.dll") ) "Test" <== ["Test.Unit"] "Build" <== ["Compile"; "Test"]
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

原則として、これはすでにローカルアセンブリを開始するのに十分です。

 PM> .\anf Build
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

（ここではパッケージマネージャーコンソールを使用しましたが、AnFakeは任意のコマンドラインコンソールから実行できます）



その結果、次のようなレポートが得られます。







コンパイルに1つの警告が渡されたことがわかります。 2つのテストが完了し、そのうちの1つはスキップされました。 OK、変更をコミットします。 コミットには、.nuget / packages.configファイル（ここではNuGetがソリューションレベルのパッケージを規定している）と、ソリューションのルートフォルダーにAnFakeをインストールするときに作成されたファイルが含まれます。



次に、TFSを介して同じアセンブリを実行します。 これを行うには、特別なAnFakeTemplate.xamlテンプレートをインストールします（チームプロジェクトで一度だけ実行されます）。

 PM> .\anf "[AnFakeExtras]/vs-setup.fsx" "BuiltTemplate" -p "TeamProject"
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

もちろん、TeamProjectの代わりに、TFSでプロジェクトの名前を置き換える必要があります。



チームは、AnFake.BuildTemplate.yyyymmdd.hhmmssという名前の一時的なワークスペースを作成します。 一時フォルダー$ / TeamProject / BuildProcessTemplatesに収縮します。 AnFakeTemplate.xamlテンプレートといくつかの関連ライブラリを追加します。 公正なinりの嵐を引き起こさないように、チームは自動的に何もコミットしません。 そのため、Visual Studio->チームエクスプローラー->保留中の変更に移動し、ワークスペースAnFake.BuildTemplateに切り替えて、変更を表示し（余分なものがないことを確認して）コミットします。



これでビルド定義を作成できます：

• Visual Studio-> Team Explorer-> Buildsに移動し、New Build Definitionを選択します。
• [プロセス]タブの[ビルドプロセステンプレート]セクションで、[詳細の表示]をクリックします。
• [新規]をクリックし、[バージョン管理パス]フィールドに次のように入力（またはソース管理エクスプローラーで選択）$ / TeamProject / BuildProcessTemplates / AnFakeTemplate.v2.xaml; [OK]をクリックします（チームプロジェクトで1回のみ実行）
• [ビルドプロセスファイル]ドロップダウンリストで、AnFakeTemplate.v2.xamlを選択して保存します。

コンテキストメニューの新しく作成された定義：キュービルドに従ってアセンブリを開始します。 その結果、次のレポートを取得します。





AnFakeTemplateテンプレートは、3つの簡単な手順を実行します。

• バージョン管理システムからソリューションを展開します。
• ソリューションレベルのNuGetパケットを復元します（つまり、AnFake自体をダウンロードします）。
• AnFakeに制御を移します。
• 他のすべてはスクリプトですでに定義されています。

テンプレートは非常にシンプルで、多くのバージョンとの互換性を維持しています。 これにより、テンプレートを更新することなくAnFakeパッケージをアップグレードできます。 異なるソリューションで異なるバージョンのAnFakeを使用することもでき、それらは1つのテンプレートで安全に組み立てられます。



TFSで基本的なAnFake統合シナリオを示しました。 ただし、統合はテンプレートに限定されません。現在のアセンブリのプロパティにスクリプトからアクセスできます。 他のアセンブリの成果物にアクセスする コンベアを整理する機会さえあります。 さらに、AnFakeはマッピングとワークスペースを操作する際に追加の自動化を提供します。マッピングは残りのプロジェクトソースとともにVCSに保存でき、ワークスペースは自動的に作成および更新されます。



ここでこれらすべての利点の説明で記事をいっぱいにしたくはありませんが、このアプローチが興味深く、ツールが需要がある場合は、近い将来に続編を書きます。 結論として、記事の冒頭で説明した「理想的な」アセンブリは、現在完全に実装されており、AnFakeで機能していると言いたいと思います。 実際のスクリプトを表示することはできませんが、いくつかの興味深い抜粋をここで見ることができます 。



フィードバックに感謝します。 ありがとう