Azure DevOps Services に Team Foundation Server の展開をリファクターする
注意
Team Foundation Server (TFS) 2019 のリリースでは、TFS の名前が Azure DevOps Server に変更されました。 この記事の大部分では、以前のバージョンの TFS の実際の製品名と記事の意図に合わせて、今も Team Foundation Server に言及します。 たとえば、Team Foundation Server 移行ツールは、Azure DevOps Server 移行ツールと呼ばれるようになりました。
この記事では、架空の会社である Contoso がオンプレミスの Visual Studio Team Foundation Server のデプロイを、Azure の Azure DevOps Services に移行することでリファクターする方法について説明します。 このシナリオでは、Contoso の開発チームは、過去 5 年間、チームのコラボレーションとソース管理に Team Foundation Server を使用してきました。 現在、チームは、クラウドベースのソリューションに移行して、開発やテストの作業とソース管理を行いたいと考えています。 Contoso チームが Azure DevOps Services モデルに移行し、新しいクラウドネイティブ アプリケーションを開発する際に、Azure DevOps Services は重要な役割を果たします。
ビジネス ドライバー
Contoso の IT リーダーシップ チームは、ビジネス パートナーと密接に協力して将来の目標を明らかにしました。 パートナーは、開発ツールやテクノロジにあまり関心がありませんが、チームはこれらの点を把握しています。
- ソフトウェア: 中心の業務にかかわらず、Contoso を含め、すべての企業は基本的にソフトウェア企業になりました。 企業の上層部は、Contoso の IT 部門がユーザーの新しい業務慣行や顧客の新しいエクスペリエンスを利用して業務を改善する方法に関心を持っています。
- 効率化: Contoso はプロセスを合理化し、開発者とユーザーにとって不要な手順を取り除きたいと考えています。 そうすることで、顧客の要件により効率的に対応できるようになります。 Contoso の IT 部門には、時間やお金を無駄にせず、迅速に行動できることが求められています。
- 機敏性: Contoso の IT 部門は、グローバル経済における成功を実現するために、ビジネス ニーズに対しての対応力を向上させる必要があります。 市場の変化に対して、より迅速に対応できる必要があり、ビジネスの阻害要因となってはいけません。
移行の目標
Contoso クラウド チームには、Azure DevOps Services への移行に関して、次の目標があります。
- ツールを使用し、少ない手動プロセスでデータをクラウドに移行する。
- 過去 1 年間の作業項目データと履歴を移行する。
- 現在のすべてのシステム割り当てを維持し、新しいユーザー名とパスワードを作成しない。
- ソース管理については、Team Foundation バージョン管理 (TFVC) から Git に移行する。
- Git への切り替えは、コードベースの転換時にすべての作業が中止されるダウンタイム中に行う。 Git への切り替えは、ソース コードの最新バージョンのみをインポートするチップ移行です。 移行後は、最新のメイン ブランチ履歴のみが利用可能になります。
- Azure DevOps Services への移行後に Team Foundation Server へのアクセスを保持し、完全な移行を実行する前にテストを実行する。
- プロジェクト数が少ないコレクションから開始する。
- Team Foundation Server コレクションは Azure DevOps Services 組織と 1 対 1 の関係にあるため、URL は複数になる。 このモデルはコード ベースとプロジェクトの分離という現在のモデルと一致します。
提案されたアーキテクチャ
- Contoso は Team Foundation Server プロジェクトをクラウドに移行します。今後は、プロジェクトやソース管理をオンプレミスではホストしません。
- Team Foundation Server は Azure DevOps Services に移行されます。
- 現在、Contoso には
ContosoDev
という名前の Team Foundation Server コレクションが 1 つあります。これはcontosodevmigration.visualstudio.com
という Azure DevOps Services 組織に移行されます。 - 昨年のプロジェクト、作業項目、バグ、およびイテレーションは、Azure DevOps Services に移行されます。
- Contoso はその Microsoft Entra インスタンスを利用します。これは、移行計画の開始時に Azure インフラストラクチャをデプロイしたときに設定したものです。
移行プロセス
この記事で示す一般的な移行プロセスは次のとおりです。
最初に、Contoso は Team Foundation Server の実装を、サポートされるレベルまでアップグレードする必要があります。
Contoso では現在 Team Foundation Server 2017 Update 3 を実行しています。 しかし、データベースの移行を使用するには、最新の更新プログラムが適用された、サポートされているバージョンを実行する必要があります。 アップグレード バージョンとしてサポートされなくなりましたが、この架空の例では、Contoso 管理者チームが Team Foundation Server 2018 Upgrade 3 にアップグレードします。
重要
移行でサポートされている Azure DevOps Server (旧称 Team Foundation Services) のバージョンの一覧については、「Azure DevOps Server から Azure DevOps Services にデータを移行する」を参照してください。 アップグレードのサポートについては、「デプロイを最新バージョンの Azure DevOps Server にアップグレードする」を参照し、左上の [バージョン] ドロップダウンで必ずバージョンを選択してください。
サポートされているバージョンのアップグレードの詳細については、後述の「手順 3: Team Foundation Server コレクションを検証する」セクションでダウンロードする移行ツールに含まれているガイドの「第 3 章: アップグレード」を参照してください。
Team Foundation Server 移行ツールを実行し、そのコレクションを検証します。
一連の準備ファイルを作成し、テストのために移行のドライ ランを実行します。
作業項目、バグ、スプリント、コードを含む、完全な移行を実行します。
TFVC から Git へコードを移動します。
前提条件
このシナリオを実行するには、Contoso は次の前提条件を満たす必要があります。
Azure サブスクリプション
Contoso では、「サブスクリプションの管理」の説明に従ってサブスクリプションを設定します。
- Azure サブスクリプションをお持ちでない場合は、無料アカウントを作成してください。
- 無料アカウントを作成する場合、サブスクリプションの管理者としてすべてのアクションを実行できます。
- 既存のサブスクリプションを使用する場合、自分が管理者ではないなら、管理者と協力して自分に所有者または共同作成者のアクセス許可を割り当てます。
- より詳細なアクセス許可が必要な場合は、ロールベースのアクセス制御を使用した Azure Site Recovery のアクセスの管理に関する記事をご覧ください。
Azure インフラストラクチャ
Contoso は、「移行インフラストラクチャをデプロイする」で説明されているように、Azure インフラストラクチャを設定します。
オンプレミスの Team Foundation Server インスタンス
この架空の例のオンプレミス インスタンスは、Team Foundation Server 2018 Upgrade 3 を稼働しているか、このプロセスの一環としてそちらにアップグレードする必要があります。
シナリオのステップ
Contoso の管理者は、次のようにして移行を完了します。
- ステップ 1:Azure Storage アカウントを作成する。 このストレージ アカウントは、移行プロセス中に使用されます。
- 手順 2:Team Foundation Server をアップグレードする。 移行をサポートするバージョンの Azure DevOps Server にデプロイをアップグレードします。
- ステップ 3:Team Foundation Server コレクションを検証する。 移行の準備として Team Foundation Server コレクションを検証します。
- 手順 4:移行ファイルを作成する。 Team Foundation Server 移行ツールを使用して移行ファイルを作成します。
- 手順 5: Azure DevOps Services への移行 準備が完了したので、Contoso の管理者は移行に専念できます。
ステップ 1: Azure Storage アカウントを作成する
Azure portal で、
contosodevmigration
という名前のストレージ アカウントを作成します。フェールオーバーに使用するセカンダリ リージョン (米国中部) にアカウントを配置します。 ローカル冗長ストレージには標準アカウントを使用します。
関連項目:
手順 2:Team Foundation Server をアップグレードする
次の一般的な手順を使用して、Team Foundation Server インスタンスを、移行をサポートするAzure DevOps Server のバージョンにアップグレードします。 いずれの場合も、左上の [バージョン] ドロップダウンで必ずバージョンを選択してください。
- 「デプロイを最新バージョンの Azure DevOps Server にアップグレードする」をご確認ください。
- 最新のダウンロードについては、「Azure DevOps Server ダウンロード」を参照してください。
- オンプレミスの Azure DevOps の要件を確認します。
- リリース ノートをご覧ください。
Contoso 管理者がサーバーを Team Foundation Server 2018 Update 3 にアップグレードするために実行した手順の例を次に示します。
VMware 仮想マシン (VM) 上で実行されている Team Foundation Server インスタンスをバックアップし、VMware のスナップショットを作成します。
Team Foundation Server のインストーラが開始されます。
インストール場所を選択します。 インストーラにはインターネット アクセスが必要です。
インストールが完了すると、サーバー構成ウィザードが起動します。
[ようこそ] ページで [次へ] をクリックして続行します。
サーバー構成ウィザードの設定を確認して同意すると、アップグレードが完了します。
プロジェクト、作業項目、コードを確かめて Team Foundation Server のインストールを確認します。
Note
一部の Team Foundation Server アップグレードでは、アップグレードの完了後に機能の構成ウィザードを実行する必要があります。 詳細については、アップグレード後の機能の構成に関するページを参照してください。
関連項目:
Team Foundation Server のアップグレードに関するページを参照してください。
手順 3:Team Foundation Server コレクションを検証する
Contoso の管理者は、移行前に contosodev
コレクション データベースに対して Team Foundation Server 移行ツールを実行して検証します。
Team Foundation Server 移行ツールをダウンロードして解凍します。 ダウンロード ページには、サポートされている 3 つの最新バージョンの移行ツールを含む 3 つの .zip ファイルがあります。 現在実行しているバージョンを確認するには、管理コンソールを参照してください。
移行時に Contoso 管理者が使用したバージョン情報とダウンロードの選択を次に示します。
プロジェクト コレクションの URL を指定して、検証を実行する移行ツールを実行します。 次に例を示します。
TfsMigrator validate /collection:http://contosotfs:8080/tfs/ContosoDev
この例では、移行ツールにエラーが表示されます。
Logs
フォルダー内のログ ファイルを見つけます。主要な検証ごとにログ ファイルが生成されます。
TfsMigration.log
は主要な情報を保持しています。ログ ファイルで、次の ID 検証エントリを探します。
コマンド ラインに
TfsMigrator validate /help
と入力します。プロジェクト コレクションとテナント ドメイン名のパラメーターを含めて検証コマンドをもう一度実行します:
TfsMigrator validate /collection:http://contosotfs:8080/tfs/ContosoDev /tenantDomainName:contosomigration.onmicrosoft.com
。Microsoft Entra サインイン ウィンドウが表示されたら、Contoso 管理者ユーザーの資格情報を入力します。
検証に合格すると、移行ツールによって確認されます。
手順 4:移行ファイルを作成する
検証が完了したので、Contoso の管理者は Team Foundation Server 移行ツールを使用して移行ファイルを作成します。
移行ツールを使用して
prepare
コマンドを実行します。TfsMigrator prepare /collection:http://contosotfs:8080/tfs/ContosoDev /tenantDomainName:contosomigration.onmicrosoft.com /accountRegion:cus
prepare
コマンドによって、次の処理が行われます。- コレクションをスキャンしてすべてのユーザーの一覧を検索し、ID マップ ログ (
IdentityMapLog.csv
) を作成します。 - Microsoft Entra ID への接続を準備し、各 ID に一致するものを検索します。
- 一致する ID を検出し、アクティブとしてマークします。
prepare
コマンドでこれが行われるのは、Contoso の管理者が既に Microsoft Entra ID をデプロイし、Microsoft Entra Connect を使用してそれを同期化しているからです。
- コレクションをスキャンしてすべてのユーザーの一覧を検索し、ID マップ ログ (
Microsoft Entra サインイン ウィンドウが表示されたら、Contoso 管理者ユーザーの資格情報を入力します。
準備が完了すると、インポート ファイルが正常に生成されたことが移行ツールによって報告されます。
IdentityMapLog.csv
ファイルとimport.json
ファイルの両方がマシン上の新しいフォルダー内に作成されたことを確認します。import.json
ファイルにはインポート設定が記録されています。 これには、組織名やストレージ アカウントの詳細などの情報が含まれています。 ほとんどのフィールドは自動的に設定されますが、一部のフィールドではユーザー入力が必要です。import.json
ファイルを開き、作成する Azure DevOps Services 組織名contosodevmigration
を追加します。この名前の場合、Contoso の Azure DevOps Services の URL は
contosodevmigration.visualstudio.com
になります。Note
組織は移行の開始前に作成しておく必要があります。 これは移行の完了後に変更することができます。
ID ログ マップ ファイルを確認します。そこには、インポート中に Azure DevOps Services に取り込まれるアカウントが示されます。
アクティブな ID とは、インポート後に Azure DevOps Services 内のユーザーになる ID のことです。
Azure DevOps Services で、これらの ID にライセンスが付与され、移行後に組織のユーザーとして表示されます。
これらの ID は、ファイルの Expected Import Status 列で Active とマークされています。 次に例を示します。
手順 5:Azure DevOps Services に移行する
準備が完了したので、Contoso の管理者は移行に専念できます。 移行を実行すると、バージョン管理には TFVC ではなく Git が使用されるようになります。
Contoso の管理者は、開始する前に開発チームと共にダウンタイムのスケジュールを設定します。そうすることで、移行に備えてコレクションをオフラインにするための計画を立てることができます。
次の移行プロセスに従ってください。
コレクションをデタッチする。 インポート中に発生した変更はインポートできないので、インポートが完了するまでは、コレクションをデタッチし、その状態を維持してください。
Team Foundation Server インスタンスからコレクションをデタッチすると、その ID データのコピーが転送のためにコレクションと共にパッケージ化されます。 インポートの ID 部分を実行するには、このデータが必要です。
コレクションの ID データは、コレクションがアタッチされ、オンラインのときは Team Foundation Server インスタンスの構成データベース内に保存されます。
バックアップを生成する。 Azure DevOps Services にインポートできるバックアップを生成します。
データ層アプリケーション コンポーネント パッケージ (DACPAC) は SQL Server の機能で、これを使用すると、データベースの変更を単一のファイルにパッケージ化し、SQL の他のインスタンスにデプロイできます。
バックアップは、Azure DevOps Services に直接復元し、コレクション データをクラウドに取り込むためのパッケージ化方法として使用できます。 Contoso の管理者は
sqlpackage.exe
ツールを使用して DACPAC を生成します。 このツールは、SQL Server Data Tools に含まれています。ストレージにアップロードします。 DACPAC が作成されたら、Azure Storage にアップロードします。
アップロード後、Shared Access Signature (SAS) が生成され、Team Foundation Server 移行ツールからストレージにアクセスできるようになります。
dry-run インポートを実行します。 DACPAC 設定など、インポート ファイル内の欠けているフィールドに入力します。 完全な移行の前にすべてが正常に機能していることを確認するため、"ドライラン" インポートを実行するよう指定します。
ドライラン インポートは、コレクションの移行をテストするのに役立ちます。 ドライ ランの有効期間は限られており、設定された期間が経過した後、および運用環境の移行が実行される前に自動的に削除されます。 インポートが完了した後に送信される成功メールには、ドライ ランが削除される時期を Contoso に通知するメモが含まれます。
運用環境の移行を完了する。 ドライランによる移行が完了したら、
import.json
ファイルを更新し、インポートを再実行して、最終的な移行を実行します。
コレクションをデタッチする
Contoso の管理者は、コレクションをデタッチする前にローカル SQL Server インスタンスのバックアップを実行し、Team Foundation Server インスタンスの VMware スナップショットを作成します。
Team Foundation Server 管理コンソールで、デタッチするコレクション (ContosoDev) を選択します。
[全般] タブを選択し、[コレクションのデタッチ] を選択します。
チーム プロジェクト コレクションのデタッチ ウィザードの [サービス メッセージ] ページで、コレクション内のプロジェクトに接続しようとするユーザー向けのメッセージを入力します。
[デタッチの進行状況] ページで進行状況を監視します。 処理が完了したら、[次へ] を選択します。
[準備チェック] ページでチェックが完了したら、[デタッチ] を選択します。
コレクションが正常にデタッチされたら、[閉じる] を選択します。
コレクションは Team Foundation Server 管理コンソールで参照されなくなります。
DACPAC を生成する
Azure DevOps Services にインポートするためのバックアップ (DACPAC) を Contoso の管理者が作成します。
Contoso の管理者は DACPAC の作成に SQL Server Data Tools (SSDT) の
sqlpackage.exe
ユーティリティを使用します。 SQL Server Data Tools と一緒にsqlpackage.exe
の複数のバージョンがインストールされ、120
、130
、140
などの名前が付いたフォルダーに配置されます。 適切なバージョンを使用して DACPAC を準備することが重要です。Team Foundation Server 2018 のインポートでは、140 以降のフォルダーの
sqlpackage.exe
を使用する必要があります。CONTOSOTFS
の場合、このファイルはC:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\Extensions\Microsoft\SQLDB\DAC\140
にあります。
Contoso の管理者は次のように DACPAC を生成します。
コマンド プロンプトを開き、
sqlpackage.exe
の場所に移動します。 DACPAC を生成するには、次のコマンドを実行します。SqlPackage.exe /sourceconnectionstring:"Data Source=SQLSERVERNAME\INSTANCENAME;Initial Catalog=Tfs_ContosoDev;Integrated Security=True" /targetFile:C:\TFSMigrator\Tfs_ContosoDev.dacpac /action:extract /p:ExtractAllTableData=true /p:IgnoreUserLoginMappings=true /p:IgnorePermissions=true /p:Storage=Memory
次に例を示します。
次のメッセージが表示されます。
DACPAC ファイルのプロパティを確認します。
ファイルをストレージにアップロードする
Contoso の管理者が、作成した DACPAC ファイルを Azure Storage アカウントにアップロードします。
Azure Storage Explorer をダウンロードしてインストールします。
Storage Explorer で、サブスクリプションに接続し、移行用に作成したストレージ アカウント (
contosodevmigration
) を検索して選択します。 新しい BLOB コンテナーazuredevopsmigration
を作成します。DACPAC ファイルのアップロードについて、[ファイルのアップロード] ペインの [BLOB の種類] ドロップダウン リストから、[ブロック BLOB] を指定します。
ファイルのアップロード後、ファイル名を選択し、[SAS の生成] を選択します。 ストレージ アカウントの [BLOB コンテナー] 一覧を展開し、インポート ファイルが含まれているコンテナーを選択して、[Shared Access Signature の取得] を選択します。
[Shared Access Signature] ページで既定の設定をそのまま使用し、[作成] を選択します。
これらの設定により、24 時間アクセスが有効になります。
Shared Access Signature の URL をコピーし、Team Foundation Server 移行ツールで使用できるようにします。
Note
許可された期間内に移行が完了する必要があります。完了しない場合、アクセス許可は期限切れになります。 Azure portal からは SAS キーを生成 "しない" でください。 ポータルから生成されたキーは、アカウント スコープであり、インポートには使用できません。
インポート設定を入力する
この記事の初めの方で、Contoso の管理者はインポート仕様ファイル import.json
の一部を入力しました。 今回は、残りの設定を追加する必要があります。
import.json
ファイルを開き、次のフィールドに入力します。
- Location: 前に生成された SAS キーの場所を入力します。
- DACPAC: 先ほどストレージ アカウントにアップロードした DACPAC ファイルの名前を入力します。.dacpac 拡張子を必ず含めてください。
- ImportType: 「DryRun」と入力します。
dry-run による移行を実行する
Contoso の管理者はドライ ラン移行を実行し、すべてが想定どおりに動作していることを確認します。
コマンド プロンプトを開き、
TfsMigrator
の場所 (C:\TFSMigrator
) に移動します。ファイルが正しく書式設定され、SAS キーが機能していることを確認するには、次のコマンドを実行してインポート ファイルを検証します。
TfsMigrator import /importFile:C:\TFSMigrator\import.json /validateonly
この検証で、SAS キーの有効期間を長くする必要があるというエラーが返されます。
Azure Storage Explorer を使用して期限切れまでの期間を 7 日間に設定した新しい SAS キーを作成します。
import.json
ファイルを更新し、コマンドTfsMigrator import /importFile:C:\TFSMigrator\import.json /validateonly
を再実行します。今度は、検証が正常に完了します。
次のコマンドを実行してドライ ランを開始します。
TfsMigrator import /importFile:C:\TFSMigrator\import.json
移行続行の確認を要求するメッセージが表示されます。 ステージング データが維持される期間がドライ ラン後 7 日間であることに注目してください。
Microsoft Entra サインイン ウィンドウが表示されたら、Contoso 管理者の資格情報を入力します。
インポートが正常に開始されたことを確認するメッセージが表示されます。
15 分後に、次の情報が Web サイトに表示されます。
移行が完了したら、Contoso の管理者として Azure DevOps Services にサインインし、ドライ ランが正常に動作したことを確認します。 認証後、要求に応じて連絡先情報を入力します。
プロジェクトが正常に移行されると、ページの上部付近に、ドライラン アカウントが 15 日後に削除されると警告する注意が表示されます。
いずれかのプロジェクトを開き、[作業項目][自分に割り当て済み] を選択します。 作業項目データが ID と共に正常に移行されたことが、このページで確認できます。
ソース コードと履歴が移行されたことを確認するために、他のプロジェクトとコードをチェックします。
運用環境の移行を実行する
ドライ ランが完了したので、Contoso の管理者は運用環境の移行を開始できます。 ドライ ランを削除し、インポート設定を更新し、インポートをもう一度実行します。
Azure DevOps Services ポータルで、ドライラン用の組織を削除します。
import.json
ファイルを更新して、ImportType
をProductionRun
に設定します。ドライ ランに使用したのと同じコマンドを実行して、移行を開始します。
TfsMigrator import /importFile:C:\TFSMigrator\import.json
移行の確認を求めるメッセージが表示されます。 セキュリティで保護されている場所に、最大 7 日間、ステージング領域としてデータを保持できるという警告が表示されます。
Microsoft Entra サインイン ウィンドウが表示されたら、Contoso 管理者の資格情報を入力します。
インポートが正常に開始されたというメッセージが表示されます。
15 分後に、次の情報が Web サイトに表示されます。
移行が完了したら、Contoso の管理者として Azure DevOps Services にサインインし、プロジェクトが正常に移行されたことを確認します。
プロジェクトを開き、[作業項目]>[自分に割り当て済み] を選択します。 このページに、作業項目データが移行されたことが示されます。
他の作業項目データが移行されていることを確認します。
他のプロジェクトとコードをチェックして、ソース コードと履歴が移行されていることを確認します。
ソース管理を TFVC から Git に移行する
移行が完了したら、次に Contoso の管理者はソース コード管理を TFVC から Git に移行する必要があります。 そのためには、管理者は、現在 Azure DevOps Services 組織内にあるソース コードを、同じ組織の Git リポジトリとしてインポートします。
Azure DevOps Services ポータルで、TFVC リポジトリ $/PolicyConnect のいずれかを開いて確認します。
ソースの [$/PolicyConnect] ドロップダウン リストから、[リポジトリのインポート] を選択します。
[ソースの種類] ドロップダウン リストから [TFVC] を選択します。 [パス] ボックスにリポジトリのパスを指定し、[インポート] を選択します。 [履歴の移行] チェック ボックスはオフのままにします。
Note
TFVC と Git とではバージョン管理情報の保存方法が異なるので、リポジトリの履歴は移行 "しない" ことをお勧めします。
インポートの完了後、コードを確認します。
2 つ目のリポジトリ (
$/smarthotelcontainer
) について、同じプロセスを繰り返します。ソースを確認したら、Azure DevOps Services への移行は完了です。 今後は Azure DevOps Services が、この移行にかかわったチームのすべての開発のソースになります。
関連項目:
移行後にクリーンアップする
移行が完了したので、Contoso チームは次のタスクを実行する必要があります。
- 追加のインポート アクティビティについては、インポート後に関する記事を参照してください。
- TFVC リポジトリを削除するか、読み取り専用モードに設定します。 コードベースは使用せず、代わりにそれらを参照して履歴を取得します。
移行後のトレーニング
Contoso チームは関連するチーム メンバーに Azure DevOps Services と Git のトレーニングを用意する必要があります。
フィードバック
https://aka.ms/ContentUserFeedback。
近日公開予定: 2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub イシューを段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、以下を参照してください:フィードバックの送信と表示