Agent Poolに登録しているAgentの削除方法

[解決したい問題]

TFS の Agent Pool に登録していたエージェントが何かの拍子でうまく削除できなかった。

サーバ側で手動で削除したい。

[回答]

ビルド エージェントのサービスを削除するには、以下の手順で実施する。

１．ビルド エージェントの構成を削除（通常はこれで問題ない）

1. エージェントを導入した PC にログインし、管理者権限でコマンド プロンプトを起動。
2. [VsoAgent.exe] があるフォルダの親フォルダにカレント ディレクトリを移動
3. 以下のコマンドを実行

.\agent\VsoAgent.exe /Unconfigure

２．エージェントの Windows サービスを削除する（上記で削除できない場合）

上記の手順で Windows サービスが削除されない場合、以下の手順で手動で削除する。

1.  Control Panel > Administrative Tool > Services より、サービス画面を表示
2. [VSO Agent] を右クリックして、Propertiesを選択
3. General タブの Service name をコピー
4. 管理者権限でコマンド プロンプトを起動
5. 以下のコマンドを実行

TFSで特定の状態になった時に、フィールドに記載がないと保存できないようにする

例えば、障害の対策完了時に必ずコメント・実績を記載するようなことは日常的に行われています。
これを強制的に実施するやり方ｗのサンプルになります。

Visual StudioからProcess EditorでTFSのテンプレートを読み込み、変更したい対象、この例ではバグがFixedになった時に必ずフィールドを設定するようにする例です。

いつやりたいかを、Field　ConditionのWhenで指定し、Whenが成立する条件（この例ではFixedのとき）を記載します。
次に、RulesでREQUIREDをしています。
これで、FIXEDの状態の時は、このフィールドに情報が入っていない場合、保存できないことになります。

[Azure 100Tips]ソースコードにアクセス出来るメンバーを制限したい(09/100)

質問

　最上位のGit Repositoryと子供のRepositoryでも同じように設定が出来るようですが、これはどのような役割があるのでしょうか？


回答
　最上位の Git Repository での設定でございますが、こちらは最上位のGit Repositoryに対するアクセス制御の設定となります。
　この最上位に対するアクセス制御を設定した場合には、既定では、最上位に設定した内容が下位の Git Repository 全てに、自動的に継承されます。
Git Repositories にアクセス制御の設定すると、下位の “Repository A”、”Repository B”、”Repository C” これらすべての Repository に対して、Git Repositories の設定が自動的に継承されます。


※これは最上位だけに限らず、すべての Repository に対しての既定の動作となっておりますため、ある Repository が下位の Repository を含む場合、既定では、常に下位の Repository は上位の Repository の設定を自動的に継承します。

上位の Repository に対し、ユーザーやグループのアクセス制御設定を追加された場合、下位の Repository にも、上位に追加されたユーザーやグループのアクセス制御設定が表示されますため、下位の Repository にて、上位から継承されている設定をご確認いただくことが可能です。

　以上の動作から、複数の Repository に対して同一の設定が必要な場合は、上位の Repository に対して設定を行い、下位の Repository でその設定を継承することで、下位の個々の Repository に対して設定を行う手間を省くことが可能です。。
※下位の一部の Repository に対して、上位の Repository の設定を適用したくない場合等は、一度上位の Repository に設定し、対象の下位のRepository の設定にて、上位から継承されている設定を変更することが可能です。

[Azure 100Tips]TFSサーバのバックアップにAzure Strageを指定する方法(06/100)

TFSサーバをAzure上のWindowsサーバに構築しており、Azure　Storageにバックアップを行う場合の手順について説明します。
TFSやAzure Storageがセットアップ済みで話をしますので、セットアップが終わってない場合はセットアップしてください。

手順
1．TFSの管理用アカウントでTFSの入っているWindowsサーバにログイン
2．Azureポータルのストレージから、ストレージのキーの取得(Strage -> All settings -> Access keys)
3．キーをOSに登録(Strage -> All settings -> Access keys)
　　　cmdkey /add:.file.core.windows.net /user:/pass:
４．Windowsサーバ上でプロンプトからネットワークドライブの割り当て
　　net use <drive-letter>: persistent:yes \\<storage-account-name>.file.core.windows.net\-name>
５．TFSの管理ツールからバックアップを設定し、ネットワークドライブではなく、フルパスを記載しバックアップ先に指定する。

以降は、バックアップの通常の設定と同じです。

[Azure 100Tips]TFSをAzure上で業務レベルで構築するための構築手順(02/100)

・1サーバでTFSをすべてまかなう場合は、ギャラリーからTeam Foundation Serverの入ったWindows Serverを選ぶか、Windows Serverをインストールして自らTeam Foundation Serverをインストールすればよい。

・可用性を考慮したサービスの構築
　TFSのWeb部分で最低2台、DB部分で最低2台の計4台のVMが必要。それ以外に、ドメインコントローラを別途構築する必要がある。
Web/DBでそれぞれ可用性セットを作成する必要がある。

マイクロソフトのサポートに相談した結果、1サーバのメンテナンス時間が年数回30分程度なので、それが我慢できるのであれば、その構成のほうが管理も楽で運用もしやすいとの事。

ご参考: Azure VM のメンテナンス FAQ

https://blogs.technet.microsoft.com/jpaztech/2016/03/25/azure-vm-sinins-maintenance-faq/

まずは、1サーバでのTFSでバックアップ体制を構築して進めることにして、技術調査を引き続き行いながら可用性の構成にシフトしたい。


Azureの可用性で誤解していた事
　VM作成時に可用性のセットを指定すれば、RAIDのミラーのように勝手に障害に対応したサービスが提供できると思っていたが、そういうわけではない。アプリケーションやサービスの冗長性（じょうちょうせい）を考慮して、それに合わせた可用性をくむ必要がある。
　
Azureの可用性のメリット
　ロードバランサーと組み合わせることでラウンドロビン方式で負荷分散をすることが出来る。