展開
すぐに使用できる TFS は実際には展開をサポートしていません。多くの場合、テスト サーバーであるビルド上の 1 つの場所に展開できます (ラボ管理を考えてください)。TFS 2012 には Azure デプロイのサポートが組み込まれていますが、ビルドの最後に引き続き発生し、ビルド アーティファクトを新しい場所に自動的にデプロイすることはできません。
ビルド テンプレートを変更して別の場所にリリースできるようにすることもできますが、それはすべての環境の新しいビルドであり、真のバイナリ プロモーションではありません。
ただし、TFS にはビルド品質の概念があり、この品質が変更されると実際にイベントが発生します。 TFS Deployerは、品質変更イベントにフックし、powershell スクリプトを実行できるサード パーティ ツールです。これは、ドロップダウン値を変更するだけで、任意の環境にリリースするスクリプトを自動的に開始できることを意味します。ビルド品質リスト (チーム コレクションごと) をカスタマイズして、スクリプトが特定のビルドをリリースする場所を特定する環境 (dev、uat、staging、production など) のリストにすることができます。
VS2012 では、Web デプロイに対するいくつかの優れた改善点もあります。これは、デプロイ構成がプロジェクトと共にソース管理に保存されることを意味します。これは、理論的には、TFS Deployer が利用できるドロップ フォルダーで利用できることを意味します。
TFS がビルド品質の履歴を保持しているとは思えません。つまり、ビルド品質の履歴を実際に使用して、どの環境に何がデプロイされたかのリストを維持することはできません。ただし、この情報はデプロイ スクリプトの一部として簡単に記録できます。または、少なくとも、リリースに関する情報を含むカスタム サマリー ノードをビルドに追加します。
TFS2012 には、Azure デプロイ機能の一部としてビルドをデプロイ済みとしてマークする機能があります。スクリプトを使用して tfs デプロイヤー ビルドをデプロイ済みとしてマークしますが、あまり便利ではありません。
Octopus Deployはチェックアウトする価値のあるもう 1 つのプロジェクトであり、ビルド テンプレートで NuGet パッケージを作成する場合は TFS Deployer の代わりに使用できます。リリースを処理するために各環境にエージェントをインストールする必要があるため、実稼働ハードウェアをもう少し制御する必要がありますが、展開に関する他の多くの問題を解決します。
バージョニング
人々が迂回しない、一貫した自動リリース方法を確立したら、ビルド テンプレートを拡張して、その自動ビルドの一部としてビルドされたもののアセンブリ バージョンとしてビルド バージョンまたは変更セット番号を挿入することを検討できます。それを行うにはさまざまな方法があり、それを実現するのに役立つブログ 投稿やツールがたくさんあります。
[assembly: AssemblyVersion("1.0.*")]または、自動アセンブリ バージョン管理 (ここは間違っているかもしれません）。
Web サイトを展開している場合は、現在のビルド バージョンを HTML のどこかに挿入することを強くお勧めします。このようにして、bin ディレクトリにアクセスしなくても、Web サイトが実行しているバージョンを確認できます。また、css/js ファイルのインポートにクエリ文字列として追加して、バージョン間でブラウザーのキャッシュが発生しないようにすることもできます。
考え
個人的には、Microsoft が、xaml ビルド ワークフローがやりすぎていること、およびさまざまな問題 (ビルド、テスト、デプロイなど) をスクリプト可能なさまざまな部分に分割していることを認識してくれることを願っています。もちろん、それは数年先の TFS の次のメジャー リリースまでではありません。Team Foundation Service を使用して、より迅速にイテレーションを行おうとしていますが、近い将来、実際には Azure の展開をより便利なものに拡張する可能性があります。