TFS 2010とNuGetterを使用して、ライブラリの新しいバージョンを自動的に公開します

与えられた

1. 1つの小さいながらも非常に便利なライブラリ。 ロギング、Windows Azureでの作業など、一般的な機能が含まれています。
2. このライブラリが使用される多数のプロジェクト（ソリューション）。
3. 分散開発チーム。ライブラリの一部が作成および保守され、他の部分は使用されるだけです。

解決したい問題

1. プロジェクトからプロジェクトにソース/バイナリをコピーする必要は不便で長く、更新中にエラーが発生する可能性が高くなります。
2. プロジェクトごとに異なるバージョンを使用できない-「過去から」特定のバージョンを見つけてアセンブルするのは不便であり、更新中にエラーが発生する可能性が高くなります。
3. ライブラリの依存関係の関連性を監視する必要性-これは特にAzure SDKに特に当てはまります。AzureSDKは現在定期的に更新されており、すべての開発者が最新バージョンを持っているわけではありません。
4. 異なるマシンで既存のプロジェクトを使用することは、多くの不必要なエラーを生成する別の「微妙な」場所です。 正しく動作させるには、プロジェクトのパスを完全に一致させる必要がありますが、これは非常に困難です。

解決策と発生した問題

ソリューションをビルドするときにライブラリの最新/特定バージョンのパッケージを取得するのがNuGetを使用するのが最も簡単であることがすぐに明らかになりました。AzureSDKでの作業も同様のアプローチです。



ただし、リポジトリを展開した後、NuGetの公開はそのようにはセットアップできないことが判明しました。公開用のパッケージを収集してリポジトリにアップロードする別のプロジェクトを作成する必要がありました。

また、 AssemblyInfo



ファイルのバージョン番号はあまり便利ではないことが判明しました-デフォルトの番号付けには公開日が含まれていないため、ライブラリの更新後に発生する問題を解決するのが多少困難になります）



その結果、公開プロセスをTFSサーバーに転送し、ライブラリのビルド定義（build）を追加することが決定されました。 これらすべてのアクションはTeam Explorer VS 2010で実行されましたが、VS 2012に切り替えたときに特別な違いはありませんでした。

最高の検索

サポートプロジェクトとして、 NFSの追加（サーバーでのビルド中のAssemblyInfo



ファイルの編集）とともにNuGetterが選択され（サーバーでのビルド中のリポジトリへの自動公開用）、プロジェクトの作成者が唯一のものであり、統合の問題はありません。

個人的な実装経験の段階的な説明

以下に書かれているものはすべて、両方のプロジェクトのドキュメントに加えて、私が遭遇したいくつかの副作用の説明に従っていることをすぐにお知らせしたいと思います。

私は以前はビルドを構成する必要がなかったので、すべての手順を十分に詳細で退屈に説明します。



0. 構成の準備-サーバーにアップロードします。



両方のプロジェクトには、サーバー上のビルドワークフロー用に定義されたカスタムアクションを含むライブラリと、デフォルトのビルド機能を拡張するワークフローテンプレートを含むxamlファイルが含まれています。 このすべてをサーバーにアップロードする必要があります。新しいビルドを作成するときにそれらを選択できるようにするためのプロジェクトテンプレートと、このビルドが次回開催されたときにそれらを見つけることができるライブラリです。



デフォルトのテンプレートを保存するためのフォルダーにワークフローテンプレートを配置することをお勧めします$/(Solution Name)/BuildProcessTemplates



。

ライブラリとその設定を含むNuGet.exeファイルを別のフォルダーに配置することをお勧めします（サーバーでは、非常に元の名前が.nuget



が、常に最上部にあり、ビルドのセットアップ時に便利です）。



ビルドプロセスでこれらのライブラリを見つけるには、このソリューションのビルドコントローラーを構成する必要があります。 これは次のように行われます。

チームエクスプローラー->（ソリューション名）->ビルド->右クリック->ビルドコントローラーの管理...





コントローラーの選択：





（ソリューション名）のコントローラーの編集：





[ Version control path to custom assemblies



のVersion control path to custom assemblies



フィールドで、共有ライブラリフォルダーへのパスを指定する必要があります。



ここで最初の小さな問題がありました- コントローラーではなく、そのビルドエージェントのプロパティを編集しようとしました。 注意してください。

念のため、フォルダーへの接続を確認します（[接続のTest Connection



]ボタン）。

接続を確認したら、変更を保存します。



1. テンプレートに基づいて新しいビルドを追加します。



ここで、前のステップでロードされたテンプレートに従って新しいビルドを追加する必要があります。 これは次のように行われます。

チームエクスプローラー->（ソリューション名）->ビルド->右クリック->新しいビルド定義...





ビルドの名前と説明：





ビルドを起動するスケジュール：



オプション：

• 手動でのみ実行します。
• 開発者からの各チェックイン後。
• 前のビルドが完了するまで待ちます。
• 開始時間を「N分以内」に設定できるチェックインの収集。
• マージが成功し、その後のサーバー上のアセンブリが成功した場合にのみ、チェックインを受け入れます。
• スケジュール通り。

ビルド中に収集する必要があるコード：



ここにプロジェクトが多すぎる場合-不要なプロジェクトを削除します。 ビルド中にどのフォルダーのどのプロジェクトをコピーするかを指定することもできます。



ビルドのデフォルトパラメータの定義：



以下を選択する必要があります。

• 前の段落で構成されたコントローラー。
• コードを配置する場所：
  
  
  • アセンブリの結果をどこにもコピーしないでください。
  • ビルド結果を共有フォルダーにコピー
    
    \\server\share
    
    
    
    という形式の有効なUNCアドレス\\server\share
    
    
    
    必要です 。
  • ビルド結果をTFSサーバーフォルダーにコピーする
    
    ビルドを作成するユーザーの権限によっては、このオプションは常に使用できるとは限りません 。

ビルド設定：



最初の3つのポイントは、どのビルドでも常に使用可能な設定です。 ここで、最初のブロックのみが重要です-アセンブリのプロジェクトまたはソリューションの選択（ Projects to Build



）。



また、 Build number format



も注意を払う価値がありBuild number format



-このパラメーターは、ビルド結果のあるフォルダーの名前を担当します（フォルダーのネストが大きいプロジェクトの場合は、それほど長くしないでください）。



ビルド結果を保存するための設定：





2. ビルド用のテンプレートを選択します。



上部の[ Process



]タブのドロップダウンリストで、必要なテンプレートを選択します。 必要なものがドロップダウンリストに表示されない場合、それが初めて使用されることを意味し、 New...



ボタンを使用してサーバーに「表示」する必要があります（TFSサーバーに既にアップロードされたファイルを選択またはコピーします）。 プリン、これはアリス、アリス、これはプリンです。



テンプレートの選択：





オプション：

• [TFSサーバーにインストールされているすべてのビルドテンプレート]。
• VersioningBuildTemplate.xaml
  
  
  
  -AssemblyInfo.csファイル内のバージョンを置き換えるための基本テンプレート。
• VersioningBuildTemplate15.xaml
  
  
  
  -AssemblyInfo.csファイルの置換用テンプレート-バージョンTFSVersioning 1.5で利用可能なライブラリプロパティを編集するための追加機能。
• NuGetterStandardBuildTemplate.xaml
  
  
  
  ビルド結果をNuGetに公開するための基本テンプレート。
• NuGetterVersioningBuildTemplate.xaml
  
  
  
  ビルド結果をNuGetに公開し、AssemblyInfo.csファイルのバージョンを置き換えるための基本的なテンプレート。
• NuGetterVersioningBuildTemplate15.xaml
  
  
  
  ビルド結果をNuGetに公開し、AssemblyInfo.csファイルをバージョンTFSVersioning 1.5の追加機能に置き換えるためのテンプレート。

3. AssemblyInfo.csファイルで置換を構成します。



TFSVersioningが参加するテンプレートが選択された場合、ビルド設定が表示されます

ポイント番号4：



必要なものと理由：

• 最初の2行は、 AssemblyFileVersion
  
  
  
  およびAssemblyVersion
  
  
  
  バージョン番号テンプレートを担当します。
• バージョン番号テンプレートの置換ルール：
  
  
  • テンプレート内の任意の場所にある番号は変更されません。
  • B
    
    
    
    は1日以内にビルド番号に置き換えられます。
  • YYYY
    
    
    
    は、現在の年の4桁の表現に置き換えられます。
  • YY
    
    
    
    は、現在の年の2桁の表現（最後の2桁）に置き換えられます。
  • MM
    
    
    
    またはM
    
    
    
    は現在の月番号に置き換えられます （ MM
    
    
    
    置き換える場合MM
    
    
    
    ゼロは前に付きません ）。
  • DD
    
    
    
    またはD
    
    
    
    は、その月の当日の数値に置き換えられます （ DD
    
    
    
    置き換える場合DD
    
    
    
    ゼロは前に付きません ）。
  • J
    
    
    
    はYYDDD
    
    
    
    形式の日付に置き換えられます。 YYDDD
    
    
    
    で、 DDD
    
    
    
    は年初からの通算日です。
  
  
  提案されているデフォルトのテンプレート1.0.JB
  
  
  
  は、ライブラリにほぼ一意のバージョン番号を提供します。 プロジェクトのメジャーバージョンとマイナーバージョンが保持されていれば、100年後に問題が始まります。 レガシーコードが反撃します。
  
  
• 3行目は、組み立てられたプロジェクトでAssemblyInfoファイルを見つけるためのマスクです。 通常、編集は必要ありません。
• 4行目は、番号B
  
  
  
  追加される番号ですB
  
  
  
  1つのプロジェクトに複数のビルドを構成する場合に使用できます。1つに100、もう1つに200を追加すれば、誰もが満足します。 ビルド番号とプレフィックスの合計の最大値は65535です。 また、プロジェクトの作成者は、1日に999を超えるビルドを作成する場合は、彼に連絡するように依頼します。
• 5行目は、 AssemblyFileVersion
  
  
  
  およびAssemblyVersion
  
  
  
  属性が欠落している場合に作成するかどうかを示します。
• 6行目は、変更されたAssemblyInfoファイルをデータストアにアップロードするかどうかを示します。

複数のプロジェクトをビルドしている場合、またはビルドの結果に基づいてNuGetパッケージを作成している場合、バージョン番号のテンプレートを別のXMLファイルに転送し、サーバーにアップロードして、7行目で使用可能にし、8行目でそのパスを示します。

XMLは次のようになります。

 <?xml version="1.0" encoding="utf-8" ?> <VersionSeed> <Solution name="Default"> <AssemblyVersionPattern>1.8.jb</AssemblyVersionPattern> <AssemblyFileVersionPattern>1.8.jb</AssemblyFileVersionPattern> </Solution> <NuGetPackage id="ServiceLib"> <VersionPattern>1.8.jb</VersionPattern> </NuGetPackage> </VersionSeed>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

TFSVersioning 1.5のビルドテンプレートを使用する場合も利用可能になります

AssemblyInfoファイルの追加の自動修正機能を備えたタブ：





4. NuGetでの公開のセットアップ。



NuGetterのテンプレートを使用する場合、さらに3つのタブを使用できます。

NuGetter（A）-事前包装：



最初のタブは、パッケージ化および公開用に組み立てられたプロジェクトの準備を担当します。 必要に応じて、PowerShellスクリプトをサーバーに追加できます（たとえば、NuGet仕様で指定されたフォルダーを作成するため）。



注意：実行可能なPowerShellスクリプトは 、サーバーでの実行が禁止されている場合があります。 この場合、 ビルドはエラーになりませんが、スクリプトが正常に機能したかのようにNuGetを実行しようとします。

PowerShellスクリプトの実行に関するポリシーは、コマンドを使用して確認および修正できます。

 Get-ExecutionPolicy Set-ExecutionPolicy
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

NuGetter（B）-パッケージ：



必要なものと理由：

• 最初の行は、NuGetファイルを実行するための追加パラメーターです。
• 2行目は、パックおよび公開時にNuGetコマンドを実行するためのベースフォルダーの名前です。
• 3行目は、サーバー上のNuGetファイルへのパスです（ファイルは、サーバー上のWindowsのPATHで定義されたリポジトリまたはフォルダー内にある必要があります ）。
• 4行目は、サーバー上のNuGet仕様ファイルへのパスです（ファイルはリポジトリ内にある必要があります）。
• 5行目は、パッケージが作成されるフォルダーの名前です（アセンブリが成功した場合）。
• 6行目-プロジェクトのバージョンテンプレートを含むファイルのアドレス-上記のように、プロジェクトとパッケージのすべてのバージョン番号を個別のXMLファイルに入れ、ビルドプロパティで常に変更しないでください。

NuGetファイルが実行前にそれ自体を更新するようにワークフローを構成できませんでした。NuGet.exeの新しいバージョンをサーバーにアップロードする必要がありました。 別のNuGet呼び出しでカスタムアクションを追加する、提供されたテンプレートに基づいて独自のテンプレートを作成する必要があると思います。 おそらく、私は自転車を発明しており、すべてがはるかに簡単になりました。



NuGetter（C）-プッシュおよび公開：



必要なものと理由：

• パッケージが公開されているNuGetリポジトリに定義されている場合、最初の行はAPIキーです。 作成者は aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee
  
  
  
  エントリのキーとしてGUIDを想定しています。指定されたキーがReGexチェックに合格しない場合、その行はAPIキーが指定されているファイルへの相対パスと見なされます 。
• 2行目は、パッケージを作成してリポジトリにコピーするだけか、リモートサーバーでの公開が必要かを示しています。 実際、フラグがオンの場合、バージョン2.1ではパラメーターが認識されないため、 -co
  
  
  
  パラメーターがNuGetスタートアップパラメーターに追加され、ビルド全体が破壊されます。
• 3行目は、パッケージの作成後にリポジトリにパッケージを公開するかどうかを示します。
• 4行目は、公開用のNuGetリポジトリのアドレスです。
  
  可能な値：
  
  
  • リモートリポジトリのURL。
  • ローカルネットワーク上のフォルダーのUNC名。
  • ビルドを開始するサーバー上のフォルダーのローカルアドレス。
  
  
  

追加なしで、標準のNuGetサーバーを使用します 。



NuGetリポジトリに正常に公開するには、アプリケーションプールを実行しているユーザーのパッケージフォルダーへの書き込み権限が必要です。 EventLogに十分なディスク領域がない場合のエラーは非常に奇妙で、まったく情報がないため、サーバーには十分なメモリが必要です。



5. ビルドを起動します。



ポイント1からの設定に従って自動的にビルドを開始することに加えて、ビルドを手動で開始できます。

チームエクスプローラー->（ソリューション名）->ビルド->起動するビルド->右クリック->新しいビルドのキュー...





現在のステータスで実行中のビルドの表：





6. 合計



この問題は解決され、この記事の執筆よりもはるかに高速になりました。 さらに、TFSでビルドを作成する手法を理解した後、Continious Integrationのセットアップはそれほど難しくないことがわかりました。 ビルドのビルドはサーバーで行われることを忘れないでください。プロジェクト設定、ファイル、その他の変更をリポジトリにアップロードすることを忘れないでください。



ビルドが失敗した場合、TFSは緊急度が緊急のバグを自動的に作成し、最後にサーバーにコードをアップロードした開発者にハングアップします。 修正後、バグはNetwork Service



割り当てられるため、この特定のユーザーには書き込み権限を付与する必要があります。



この記事が時間と神経を節約することを願っています。

ご清聴ありがとうございました。