共用方式為

執行測試執行移轉

  • 發行項

您的小組現在已準備好開始開始進行移轉測試回合的程式，最後是完整的生產環境移轉。 在此階段中，除了通常會在移轉項目結束時出現的其他工作之外，我們也會討論將移轉排入佇列的最後步驟。

圖表醒目提示循序階段的必要條件階段。

必要條件

開始測試回合移轉之前，請先完成準備測試回合階段。

驗證集合

驗證您想要移轉至 Azure DevOps Services 的每個集合。 驗證步驟會檢查集合的各個層面，包括但不限於大小、定序、身分識別和程式。

使用資料遷移工具執行驗證。

  1. 下載數據遷移工具。

  2. 將 zip 檔案複製到其中一個 Azure DevOps Server 應用層。

  3. 將 檔案解壓縮。 您也可以從未安裝 Azure DevOps Server 的不同機器執行此工具，只要機器可以連線到 Azure DevOps Server 實例的組態資料庫即可。

  4. 開啟伺服器上的 [命令提示字元] 視窗，然後輸入 cd 命令，以變更為儲存資料遷移工具的目錄。 請花點時間檢閱工具的說明內容。

    a. 若要檢視最上層的說明和指引，請執行下列命令。

     Migrator /help

    b. 檢視命令的說明文字。

     Migrator validate /help

  5. 當您第一次驗證集合時，您的命令應該具有下列簡單結構。

     Migrator validate /collection:{collection URL} /tenantDomainName:{name} /region:{region}

    其中 {name} 提供您Microsoft Entra 租用戶的名稱，例如，若要針對 DefaultCollection 和 fabrikam 租使用者執行，命令看起來會像下列範例一樣。

     Migrator validate /collection:http://localhost:8080/DefaultCollection /tenantDomainName:fabrikam.OnMicrosoft.com /region:{region}

  6. 若要從 Azure DevOps Server 以外的電腦執行此工具，您需要 /connectionString 參數。 連接字串 參數會指向您的 Azure DevOps Server 組態資料庫。 例如，如果 Fabrikam 公司執行已驗證的命令，此命令看起來會像這樣。

     Migrator validate /collection:http://fabrikam:8080/DefaultCollection /tenantDomainName:fabrikam.OnMicrosoft.com /region:{region} /connectionString:"Data Source=fabrikam;Initial Catalog=Configuration;Integrated Security=True"

    重要

    數據遷移工具 不會 編輯集合中的任何數據或結構。 它只會讀取集合來識別問題。

  7. 驗證完成後，您可以檢視記錄檔和結果。

    命令提示字元視窗中驗證結果和記錄的螢幕快照。

    在驗證期間，如果某些管線包含每個管線保留規則，您會收到警告。 Azure DevOps Services 會使用 以專案為基礎的保留模型 ，且不支援每個管線保留原則。 如果您繼續進行移轉，則原則不會延續至裝載的版本。 相反地，會套用預設專案層級保留原則。 保留組建對於您而言很重要，以避免其遺失。

所有驗證通過之後，您就可以移至 移轉程式的下一個步驟。 如果數據遷移工具標幟任何錯誤，請先更正錯誤，再繼續進行。 如需修正驗證錯誤的指引，請參閱 針對移轉和移轉錯誤進行疑難解答。

匯入記錄檔

當您開啟記錄檔目錄時，您可能會注意到數個記錄檔。

主要記錄檔名為 DataMigrationTool.log。 其中包含已執行之所有專案的詳細數據。 為了讓您更輕鬆地專注於特定區域，記錄會產生每個主要驗證作業。

例如，如果 TfsMigrator 在「驗證項目進程」步驟中報告錯誤，您可以開啟 ProjectProcessMap.log 檔案，以檢視針對該步驟執行的所有專案，而不需要捲動整個記錄檔。

只有在您嘗試移轉項目程式以使用繼承的模型時，才檢閱TryMatchOobProcesses.log檔案。 如果您不想使用繼承的模型，您可以忽略這些錯誤，因為它們不會阻止您匯入 Azure DevOps Services。 如需詳細資訊，請參閱 驗證移轉階段。

產生移轉檔案

數據遷移工具已驗證集合，並傳回「所有已傳遞的集合驗證」的結果。將集合脫機移轉之前，請先產生移轉檔案。 當您執行 命令時 prepare ，會產生兩個移轉檔案：

  • IdentityMapLog.csv：概述 Active Directory 與 Microsoft Entra 標識符之間的身分識別對應。
  • migration.json：要求您填寫您想要用來開始移轉的移轉規格。

準備命令

命令 prepare 可協助產生必要的移轉檔案。 基本上，此命令會掃描集合以尋找所有用戶的清單，以填入身分識別對應記錄檔， IdentityMapLog.csv，然後嘗試連線到 Microsoft Entra ID 以尋找每個身分識別的相符專案。 若要這樣做，您的公司必須使用 Microsoft Entra Connect 工具（先前稱為目錄同步處理工具 、目錄同步工具或DirSync.exe工具）。

如果設定目錄同步處理，數據遷移工具應該會尋找相符的身分識別，並將其標示為 作用中。 如果沒有相符專案，身分識別會在身分識別對應記錄中標示為 [歷程 記錄]，因此您必須調查用戶為何未包含在目錄同步處理中。移轉規格檔案 migration.json應該在移轉之前填入。

validate與 命令不同， prepare 需要因特網連線，因為它必須連線到 Microsoft Entra ID 以填入身分識別對應記錄檔。 如果您的 Azure DevOps Server 實例沒有因特網存取權，請從執行的機器執行此工具。 只要您可以找到具有 Azure DevOps Server 實例和因特網連線內部網路連線的電腦，您就可以執行此命令。 如需命令的說明 prepare ，請執行下列命令：

Migrator prepare /help

說明檔中包含的指示和範例可從 Azure DevOps Server 實例本身和遠端電腦執行 Migrator 命令。 如果您是從其中一個 Azure DevOps Server 實例應用層執行命令，您的命令應該具有下列結構：

Migrator prepare /collection:{collection URL} /tenantDomainName:{name} /region:{region}

Migrator prepare  /collection:{collection URL} /tenantDomainName:{name} /region:{region} /connectionString:"Data Source={sqlserver};Initial Catalog=Configuration;Integrated Security=True"

connectionString 參數是 Azure DevOps Server 實例組態資料庫的指標。 例如，如果 Fabrikam 公司執行 prepare 命令，此命令看起來會像下列範例：

Migrator prepare /collection:http://fabrikam:8080/DefaultCollection /tenantDomainName:fabrikam.OnMicrosoft.com /region:{region} /connectionString:"Data Source=fabrikam;Initial Catalog=Configuration;Integrated Security=True"

當資料遷移工具執行 prepare 命令時，它會執行完整的驗證，以確保自上次完整驗證之後，您的集合沒有任何變更。 如果偵測到任何新問題，則不會產生任何移轉檔案。

命令開始執行之後不久，就會顯示Microsoft Entra 登入視窗。 使用屬於租使用者網域的身分識別登入，該身分識別是在 命令中指定的。 請確定指定的Microsoft Entra 租使用者是您希望未來組織支援的租使用者。 在我們的 Fabrikam 範例中，使用者輸入類似下列範例螢幕快照的認證。

重要

請勿將測試Microsoft Entra 租使用者用於測試移轉，而您的實際執行Microsoft Entra 租使用者。 使用測試Microsoft Entra 租使用者，當您開始使用組織的生產Microsoft Entra 租使用者執行生產環境時，可能會導致身分識別移轉問題。

當您在資料遷移工具中成功執行 prepare 命令時，結果視窗會顯示一組記錄和兩個移轉檔案。 在記錄目錄中，尋找logs資料夾和兩個檔案：

  • migration.json是移轉規格檔案。 建議您花點時間填寫。
  • IdentityMapLog.csv包含 Active Directory 與 entra 身分識別Microsoft產生的對應。 開始移轉之前，請先檢閱其完整性。

下一節會更詳細地說明這兩個檔案。

移轉規格檔案

移轉規格 migration.json是提供移轉設定的 JSON 檔案。 其中包含所需的組織名稱、記憶體帳戶資訊和其他資訊。 大部分欄位都會自動填入，有些字位需要輸入才能嘗試移轉。

新產生的移轉規格檔案螢幕快照。

下表說明migration.json檔案的顯示欄位和必要動作：

欄位 描述 必要的動作
來源 移轉之源資料檔的位置和名稱的相關信息。 不需要執行任何動作。 檢閱子欄位動作要遵循的資訊。
Location 裝載資料層應用程式套件 （DACPAC） 的 Azure 記憶體帳戶共用存取簽章密鑰。 不需要執行任何動作。 此欄位會在稍後的步驟中說明。
檔案 包含移轉資料的檔名。 不需要執行任何動作。 檢閱子欄位動作要遵循的資訊。
DACPAC DACPAC 檔案，封裝在移轉期間用來帶入數據的集合資料庫。 不需要執行任何動作。 在稍後的步驟中，您會使用您的集合建立此檔案，然後將它上傳至 Azure 儲存器帳戶。 根據您稍後在此程式中產生檔案時所使用的名稱來更新檔案。
Target 要移轉至之新組織的屬性。 不需要執行任何動作。 檢閱子欄位動作要遵循的資訊。
名稱 移轉期間要建立的組織名稱。 提供名稱。 移轉完成後，可以快速變更名稱。
注意： 在執行移轉之前，請勿 使用此名稱建立組織。 組織會建立為移轉程式的一部分。
ImportType 您要執行的移轉類型。 不需要執行任何動作。 在稍後的步驟中，選取要執行的移轉類型。
驗證數據 協助推動移轉體驗所需的資訊。 數據遷移工具會產生 「ValidationData」 區段。 其中包含可協助推動移轉體驗的資訊。 請勿* 編輯本節中的值，或您的移轉可能無法啟動。

完成上述程序之後，您應該會有類似下列範例的檔案。

部分完成移轉規格檔案的螢幕快照。

在上圖中，Fabrikam 移轉規劃工具新增了組織名稱 fabrikam-import，並將選取的 CUS （Central 美國） 新增為移轉的地理位置。 其他值則保留為在規劃工具離線進行移轉之前修改。

注意

測試回合匯入會自動附加至組織名稱結尾的 '-dryrun'，您可以在移轉后變更。

支援的 Azure 區域以進行移轉

Azure DevOps Services 可在數個 Azure 地理位置中使用。 但是，並非所有可用的 Azure DevOps Services 位置都支援移轉。 下表列出您可以選取以進行移轉的 Azure 地理位置。 此外，也包含您需要在移轉規格檔案中放置的值，以針對該地理位置進行移轉。

地理位置 Azure 地理位置 匯入規格值
美國 中央 美國 CUS
歐洲 西歐 WEU
英國 英國南部 UKS
澳大利亞 澳大利亞東部 EAU
南美洲 巴西南部 SBR
亞太地區 印度南部 MA
亞太地區 東南亞 (新加坡) SEA
加拿大 加拿大中部 CC

身分識別對應記錄

身分識別對應記錄與您移轉至 Azure DevOps Services 的實際數據同等重要。 當您檢閱檔案時，請務必瞭解身分識別移轉的運作方式，以及可能的結果。 當您移轉身分識別時，它可能會變成 作用中 或 歷程記錄。 作用中身分識別可以登入 Azure DevOps Services，但歷程記錄身分識別無法登入。

使用中身分識別

作用中身分識別是指移轉后 Azure DevOps Services 中的使用者身分識別。 在 Azure DevOps Services 中，這些身分識別會獲得授權，並顯示為組織中的使用者。 身分識別會在身分識別對應記錄檔的 [預期匯入狀態] 數據行中標示為作用中。

歷史身分識別

歷程記錄身分識別會對應，例如在識別對應記錄檔的 [預期匯入狀態 ] 數據行中。 檔案中沒有行專案的身分識別也會變成歷程記錄。 沒有行輸入的身分識別範例可能是不再在公司工作的員工。

不同於作用中身分識別，歷史身分識別：

  • 移轉后無法 存取組織。
  • 沒有 授權。
  • 不要 顯示為組織中的使用者。 保存的所有專案都是組織內該身分識別名稱的概念，以便稍後搜尋其歷程記錄。 我們建議您針對不再在公司工作或不需要進一步存取組織的使用者，使用歷程記錄身分識別。

注意

將身分識別匯入為歷程記錄之後，就無法變成作用中。

瞭解身分識別對應記錄檔

身分識別對應記錄檔類似於此處所示的範例：

數據遷移工具所產生的身分識別對應記錄檔螢幕快照。

下表說明身分識別對應記錄檔中的數據行：

您和您的Microsoft Entra 系統管理員必須調查標示為 「找不到相符專案」的使用者（檢查Microsoft Entra ID Sync）， 以了解他們為何不屬於您Microsoft Entra Connect 同步處理。

資料行 描述
Active Directory：使用者 （Azure DevOps Server） Azure DevOps Server 中身分識別所使用的易記顯示名稱。 此名稱可讓您更輕鬆地識別對應中線條所參考的使用者。
Active Directory：安全性標識符 Azure DevOps Server 中 內部部署的 Active Directory 身分識別的唯一標識符。 此數據行用來識別集合中的使用者。
Microsoft項目標識符：預期的匯入使用者 （Azure DevOps Services） 相符的近期作用中使用者的預期登入位址或 找不到相符專案 （檢查Microsoft Entra ID Sync）的預期登入位址，這表示在Microsoft Entra ID Sync 期間遺失身分識別，並匯入為歷程記錄。
預期的匯入狀態 預期的使用者移轉狀態： 如果您的 Active Directory 與 Microsoft Entra 標識符之間有相符專案，則為 Active ，如果沒有 相符專案，則為 [歷程記錄 ]。
驗證日期 上次驗證身分識別對應記錄的時間。

當您閱讀檔案時，請注意預期的匯入狀態數據行中的值為 [作用中] 或 [歷程記錄]。 作用 中表示此數據列上的身分識別會在移轉時正確對應為作用中。 歷程 記錄表示身分識別會在移轉時變成歷程記錄。 請務必檢閱產生的對應檔案，以取得完整性和正確性。

重要

如果移轉嘗試之間發生重大變更，則移轉會失敗Microsoft Entra Connect 安全性標識碼同步。 您可以在測試回合之間新增使用者，而且可以進行更正，以確保先前匯入的歷程記錄身分識別變成作用中。 但是，您無法變更先前匯入為作用中的現有使用者。 這樣做會導致您的移轉失敗。 變更的範例可能是完成測試回合移轉、從主動匯入的 Microsoft Entra 標識碼刪除身分識別、重新建立相同身分識別的 Microsoft Entra ID 中的新使用者，然後嘗試另一個移轉。 在此情況下，Active Directory 與新建立Microsoft Entra 身分識別之間的作用中身分識別移轉嘗試，但會導致移轉失敗。

  1. 檢閱正確相符的身分識別。 所有預期的身分識別都存在嗎？ 使用者是否對應至正確的Microsoft Entra 身分識別？

    如果必須變更任何值，請連絡您的 Microsoft Entra 系統管理員，確認 內部部署的 Active Directory 身分識別是否為同步處理的一部分，以Microsoft Entra ID 並正確設定。 如需詳細資訊，請參閱 整合內部部署身分識別與Microsoft Entra ID。

  2. 接下來，檢閱標示為 歷程記錄的身分識別。 此標籤表示找不到相符Microsoft Entra 身分識別，原因如下：

    • 身分識別未設定為 內部部署的 Active Directory 與Microsoft Entra標識符之間的同步處理。
    • 身分識別尚未填入您的Microsoft Entra識別符（例如，有新員工）。
    • 身分識別不存在於您的 Microsoft Entra 實例中。
    • 擁有該身分識別的使用者不再在公司工作。

若要解決前三個原因，請設定預期的 內部部署的 Active Directory 身分識別，以與 Microsoft Entra 標識符同步。 如需詳細資訊，請參閱 整合內部部署身分識別與Microsoft Entra ID。 您必須設定並執行 Microsoft Entra Connect，才能在 Azure DevOps Services 中將身分識別匯入為 作用 中。

您可以忽略第四個原因，因為不再在公司的員工應該匯入為 歷程記錄。

歷史身份（小團隊）

注意

本節中提議的身分識別移轉策略應該只由小型小組考慮。

如果未設定Microsoft Entra Connect，則身分識別對應記錄檔中的所有用戶都會標示為 歷程記錄。 以這種方式執行移轉會導致所有用戶匯入為歷程記錄。 強烈建議您設定 Microsoft Entra Connect ，以確保您的使用者已匯入為 使用中狀態。

執行具有所有歷程記錄身分識別的移轉會產生需要仔細考慮的結果。 只有少數使用者且設定Microsoft Entra Connect 成本過高的小組應該考慮。

若要將所有身分識別移轉為歷程記錄，請遵循後續各節中所述的步驟。 當您將移轉排入佇列時，用來將移轉排入佇列的身分識別會以組織擁有者身分進入組織。 所有其他用戶都會匯入為歷程記錄。 然後 ，組織擁有者可以使用其Microsoft Entra 身分識別，將使用者新增回 去。 新增的使用者會被視為新使用者。 他們沒有自己的任何歷史，也沒有辦法將這段歷史重新歸結到Microsoft Entra 身份。 不過，使用者仍可藉由搜尋 其 來查閱其 \<domain>\<Active Directory username>預先移轉歷程記錄。

如果數據遷移工具偵測到完整的歷程記錄身分識別案例，就會顯示警告。 如果您決定前往此移轉路徑，則必須在工具中同意限制。

Visual Studio 訂閱

數據遷移工具在產生身分識別對應記錄檔時，無法偵測Visual Studio訂用帳戶（先前稱為MSDN權益）。 相反地，建議您在移轉之後套用自動授權升級功能。 只要使用者的工作帳戶 正確連結 ，Azure DevOps Services 就會在移轉後的第一次登入時自動套用其Visual Studio 訂用帳戶權益。 您永遠不會針對在移轉期間指派的授權收費，因此您可以在之後安全地處理訂用帳戶。

如果使用者的Visual Studio訂用帳戶未在 Azure DevOps Services 中自動升級，就不需要重複測試回合移轉。 Visual Studio 訂用帳戶連結會在移轉範圍之外發生。 只要在移轉前後正確連結其工作帳戶，用戶授權就會在其下一次登入時自動升級。 成功升級其授權之後，下次執行移轉時，使用者就會在其第一次登入組織時自動升級。

為移轉做準備

現在您已準備好在測試回合移轉上執行所有專案。 排程小組的停機時間，讓集合脫機進行移轉。 當您同意執行移轉的時間時，請將您產生的必要資產和資料庫的複本上傳至 Azure。 準備移轉包含下列五個步驟。

步驟 1： 讓集合離線並中斷連結。 步驟 2： 從您要移轉的集合產生 DACPAC 檔案。
步驟 3： 將 DACPAC 檔案和移轉檔案上傳至 Azure 記憶體帳戶。
步驟 4： 產生 SAS 令牌以存取記憶體帳戶。
步驟 5： 完成移轉規格。

注意

執行生產移轉之前，強烈建議您完成測試回合移轉。 透過測試回合，您可以驗證移轉程式適用於您的集合，而且沒有可能導致生產移轉失敗的唯一數據圖形。

步驟 1：中斷連結您的集合

中斷連結集合 是移轉程式中的重要步驟。 集合的身分識別數據位於 Azure DevOps Server 實例的組態資料庫中，而集合則附加並上線。 當集合與 Azure DevOps Server 實例中斷連結時，它會擷取該身分識別數據的複本，並將它與集合封裝以用於傳輸。 如果沒有此數據，就無法執行移轉的身分識別部分。

提示

建議您讓集合保持中斷連結，直到移轉完成為止，因為移轉期間沒有方法可移轉所發生的變更。 在備份集合以進行移轉之後重新附加集合，因此您並不擔心有這種類型的移轉的最新數據。 若要避免完全離線時間，您也可以選擇針對測試回合採用離。

請務必權衡選擇在測試回合中產生零停機時間的成本。 它需要建立集合和組態資料庫的備份、在 SQL 實例上還原它們，然後建立中斷連結的備份。 成本分析可能證明，只需要幾個小時的停機時間就能直接取得中斷連結的備份，最終會更好。

步驟 2：產生 DACPAC 檔案

DACPAC 提供快速且相對容易的方法，可將集合移至 Azure DevOps Services。 不過，在集合資料庫大小超過特定閾值之後，使用 DACPAC 的優點會開始減少。

注意

如果數據遷移工具顯示您無法使用 DACPAC 方法的警告，則必須使用 SQL Azure 虛擬機器 （VM） 方法來執行移轉。 在該案例中略過步驟 2 到 5，並遵循準備測試回合階段、移轉大型集合一節中的指示，然後繼續判斷移轉類型。 如果數據遷移工具未顯示警告，請使用此步驟中所述的 DACPAC 方法。

DACPAC 是 SQL Server 的功能，可讓資料庫封裝成單一檔案，並部署到 SQL Server 的其他實例。 DACPAC 檔案也可以直接還原至 Azure DevOps Services，因此您可以使用它作為封裝方法，以在雲端中取得集合的數據。

重要

  • 當您使用 SqlPackage.exe時，必須使用 .NET Framework 版本的 SqlPackage.exe 來準備 DACPAC。 MSI 安裝程式必須用來安裝 .NET Framework 版本的 SqlPackage.exe。 請勿使用 dotnet CLI 或 .zip （Windows .NET 6） 版本的 SqlPackage.exe，因為這些版本可能會產生與 Azure DevOps Services 不相容的 DACPAC。
  • 根據預設，SqlPackage 161 版會加密資料庫連線，而且可能不會連線。 如果您收到登入進程錯誤，請將 新增;Encrypt=False;TrustServerCertificate=True至 SqlPackage 語句的 連接字串。

使用 SqlPackage 版本資訊的最新 MSI 安裝程式下載並安裝SqlPackage.exe。

使用 MSI 安裝程式之後，SqlPackage.exe安裝路徑類似 %PROGRAMFILES%\Microsoft SQL Server\160\DAC\bin\。

當您產生 DACPAC 時，請記住兩個考慮：DACPAC 儲存的磁碟，以及產生 DACPAC 之電腦上的磁碟空間。 您要確保有足夠的磁碟空間來完成作業。

建立封裝時，SqlPackage.exe暫時將集合中的數據儲存在您起始封裝要求的機器 C 磁碟驅動器 C 上的暫存目錄中。

您可能會發現磁碟驅動器 C 太小，無法支援建立 DACPAC。 您可以藉由尋找集合資料庫中的最大數據表來估計所需的空間量。 DACPAC 會一次建立一個數據表。 執行產生的最大空間需求大致相當於集合資料庫中最大數據表的大小。 如果您將產生的 DACPAC 儲存為磁碟驅動器 C，請考慮從驗證執行DataMigrationTool.log檔案中所回報的集合資料庫大小。

DataMigrationTool.log檔案會在每次執行命令時，提供集合中最大的數據表清單。 如需集合的數據表大小範例，請參閱下列輸出。 比較最大數據表的大小與裝載暫存目錄之磁碟驅動器上的可用空間。

重要

在繼續產生 DACPAC 檔案之前，請確定您的集合已 中斷連結。

[Info   @08:23:59.539] Table name                               Size in MB
[Info   @08:23:59.539] dbo.tbl_Content                          38984
[Info   @08:23:59.539] dbo.tbl_LocalVersion                     1935
[Info   @08:23:59.539] dbo.tbl_Version                          238
[Info   @08:23:59.539] dbo.tbl_FileReference                    85
[Info   @08:23:59.539] dbo.Rules                                68
[Info   @08:23:59.539] dbo.tbl_FileMetadata                     61

請確定裝載您暫存目錄的磁碟驅動器至少有一樣多的可用空間。 如果沒有，您必須藉由設定環境變數來重新導向暫存目錄。

SET TEMP={location on disk}

另一個考慮是儲存 DACPAC 資料的位置。 將儲存的位置指向離遠的遠端磁碟驅動器可能會導致產生時間更長。 如果在本機提供固態硬碟 （SSD） 等快速磁碟驅動器，建議您將磁碟驅動器作為 DACPAC 儲存位置的目標。 否則，使用位於集合資料庫所在計算機上的磁碟，而不是遠端磁碟驅動器，一律會比較快。

既然您已識別 DACPAC 的目標位置，並確定您有足夠的空間，就可以產生 DACPAC 檔案。

開啟 [命令提示字元] 視窗，並移至SqlPackage.exe位置。 若要產生 DACPAC，請將佔位元值取代為必要值，然後執行下列命令：

SqlPackage.exe /sourceconnectionstring:"Data Source={database server name};Initial Catalog={Database Name};Integrated Security=True" /targetFile:{Location & File name} /action:extract /p:ExtractAllTableData=true /p:IgnoreUserLoginMappings=true /p:IgnorePermissions=true /p:Storage=Memory
  • 數據源：裝載 Azure DevOps Server 集合資料庫的 SQL Server 實例。
  • 初始目錄：集合資料庫的名稱。
  • targetFile：磁碟上的位置和 DACPAC 檔名。

在 Azure DevOps Server 數據層本身上執行的 DACPAC 產生命令，如下列範例所示：

SqlPackage.exe /sourceconnectionstring:"Data Source=localhost;Initial Catalog=Foo;Integrated Security=True" /targetFile:C:\DACPAC\Foo.dacpac /action:extract /p:ExtractAllTableData=true /p:IgnoreUserLoginMappings=true /p:IgnorePermissions=true /p:Storage=Memory

命令的輸出是從名為 Foo.dacpac 的集合資料庫 Foo 產生的 DACPAC 檔案。

設定您的集合以進行移轉

在 Azure VM 上還原收集資料庫之後，請設定 SQL 登入以允許 Azure DevOps Services 連線到資料庫以移轉數據。 此登入只 允許單一資料庫的讀取 許可權。

若要啟動，請在 VM 上開啟 SQL Server Management Studio，然後針對要匯入的資料庫開啟新的查詢視窗。

將資料庫的復原設定為簡單：

ALTER DATABASE [<Database name>] SET RECOVERY SIMPLE;

建立資料庫的 SQL 登入，並指派該登入 『TFSEXECROLE』：

USE [<database name>]
CREATE LOGIN <pick a username> WITH PASSWORD = '<pick a password>'
CREATE USER <username> FOR LOGIN <username> WITH DEFAULT_SCHEMA=[dbo]
EXEC sp_addrolemember @rolename='TFSEXECROLE', @membername='<username>'

在 Fabrikam 範例之後，這兩個 SQL 命令看起來會像下列範例：

ALTER DATABASE [Fabrikam] SET RECOVERY SIMPLE;

USE [Foo]
CREATE LOGIN fabrikam WITH PASSWORD = 'fabrikampassword'
CREATE USER fabrikam FOR LOGIN fabrikam WITH DEFAULT_SCHEMA=[dbo]
EXEC sp_addrolemember @rolename='TFSEXECROLE', @membername='fabrikam'

注意

在 VM 上的 SQL Server Management Studio 中啟用 SQL Server 和 Windows 驗證 模式。 如果您未啟用驗證模式，移轉會失敗。

將移轉規格檔案設定為以 VM 為目標

更新移轉規格檔案，以包含如何連線到 SQL Server 實例的相關信息。 開啟您的移轉規格檔案，並進行下列更新。

  1. 從來源檔案物件中移除 DACPAC 參數。

    變更前的移轉規格會顯示在下列程式代碼中。

    變更前移轉規格的螢幕快照。

    變更之後的移轉規格會顯示在下列程式代碼中。

    變更後移轉規格的螢幕快照。

  2. 填寫必要的參數，並在規格檔案中的來源物件中新增下列屬性物件。

    "Properties":
{
    "ConnectionString": "Data Source={SQL Azure VM Public IP};Initial Catalog={Database Name};Integrated Security=False;User ID={SQL Login Username};Password={SQL Login Password};Encrypt=True;TrustServerCertificate=True" 
}

套用變更之後，移轉規格看起來像下列範例。

參考 SQL Azure VM 的移轉規格螢幕快照。

您的移轉規格現在已設定為使用 SQL Azure VM 進行移轉。 繼續進行移轉至 Azure DevOps Services 的其餘準備步驟。 移轉完成後，請務必刪除 SQL 登入或輪替密碼。 Microsoft移轉完成後不會保留登入資訊。

步驟 3：上傳 DACPAC 檔案

注意

如果您使用 SQL Azure VM 方法，則只需要提供 連接字串。 您不需要上傳任何檔案，而且可以略過此步驟。

DACPAC 必須放在 Azure 記憶體容器中，它可以是現有的容器，或專為移轉工作建立的容器。 請務必確定您的容器是在正確的地理位置中建立的。

Azure DevOps Services 可在多個 地理位置使用。 當您匯入這些位置時，請務必正確放置您的數據，以確保移轉可以順利啟動。 您的數據必須放在您要匯入的相同地理位置。 將數據放在其他地方會導致移轉無法啟動。 下表列出建立記憶體帳戶及上傳數據可接受的地理位置。

所需的移轉地理位置 記憶體帳戶地理位置
中央 美國 中央 美國
西歐 西歐
英國 英國南部
澳大利亞東部 澳大利亞東部
巴西南部 巴西南部
印度南部 印度南部
加拿大中部 加拿大中部
亞太地區（新加坡） 亞太地區（新加坡）

雖然 Azure DevOps Services 位於美國的多個地理位置，但只有 Central 美國 位置接受新的 Azure DevOps Services。 目前您無法將數據遷移至其他美國 Azure 位置。

從 Azure 入口網站 建立 Blob 容器。 建立容器之後，請上傳集合 DACPAC 檔案。

移轉完成後，請刪除 Blob 容器，並隨附記憶體帳戶與 AzCopy 或任何其他 Azure 記憶體總管工具等工具，例如 Azure 儲存體 Explorer。

注意

如果您的 DACPAC 檔案大於 10 GB，建議您使用 AzCopy。 AzCopy 具有多線程上傳支援，可加快上傳速度。

步驟 4：產生 SAS 令牌

共用存取簽章 （SAS） 令牌提供對記憶體帳戶中資源的委派存取權。 令牌可讓您提供Microsoft存取數據以執行移轉所需的最低許可權層級。

您可以使用 Azure 入口網站 產生 SAS 令牌。 從安全性觀點來看，我們建議執行下列工作：

  1. 只 選取 [讀取 ] 和 [列出 ] 作為 SAS 令牌的許可權。 不需要任何其他權限。
  2. 設定到期時間不超過未來七天的時間。
  3. 僅限制對 Azure DevOps Services IP 的存取。
  4. 將 SAS 金鑰視為秘密。 請勿將密鑰保留在不安全的位置，因為它會將您儲存在容器中的任何數據授與讀取和列出存取權。

步驟 5：完成移轉規格

稍早在程式中，您部分填寫了移轉規格檔案，稱為 migration.json。 此時，您有足夠的資訊可以完成移轉類型以外的所有其餘欄位。 稍後會在移轉區段中討論移轉類型。

在migration.json規格檔案的 [來源] 底下，完成下列欄位。

  • 位置：貼上您從腳本產生的 SAS 金鑰，然後在上一個步驟中複製。
  • Dacpac：請確定檔案，包括 .dacpac 擴展名，與您上傳至記憶體帳戶的 DACPAC 檔案同名。

最終的移轉規格檔案看起來應該像下列範例。

已完成移轉規格檔案的螢幕快照。

判斷移轉類型

匯入可以排入佇列作為測試回合或生產執行。 ImportType 參數會決定移轉類型：

  • TestRun：針對測試目的使用測試回合。 系統會在 45 天后刪除測試回合。
  • ProductionRun：當您想要保留產生的移轉，並在移轉完成後使用 Azure DevOps Services 中的組織全職時，請使用生產執行。

提示

建議您先完成測試回合移轉。

測試回合組織

測試回合組織可協助小組測試其集合的移轉。 執行生產環境移轉之前，必須先刪除任何已完成的測試回合組織。 所有測試回合組織都有 有限的存在，而且會在一段時間后自動刪除。 刪除組織何時包含在成功電子郵件中，您應該在移轉完成後收到的相關信息。 請務必記下此日期並據以規劃。

測試回合組織在刪除前 45 天。 在指定的時間週期之後，會刪除測試回合組織。 您可以在執行生產環境移轉之前，視需要重複測試回合匯入。

刪除測試回合

在您嘗試新的測試之前，請先刪除任何先前的測試回合。 當小組準備好執行生產環境移轉時，您必須手動刪除測試回合組織。 在您執行第二次測試回合移轉或最終生產移轉之前，請確定您刪除您在先前測試回合中建立的任何先前 Azure DevOps Services 組織。 如需詳細資訊，請參閱 刪除組織。

提示

選擇性資訊，可協助使用者更成功執行遵循第一個測試回合的移轉，因為需要較長的時間才能清除先前測試回合的資源。

刪除或重新命名之後，最多可能需要一小時的時間，組織名稱才會可供使用。 如需詳細資訊，請參閱 移轉後工作 一文。

如果您遇到任何移轉問題，請參閱 針對移轉和移轉錯誤進行疑難解答。

執行移轉

您的小組現在已準備好開始執行移轉的程式。 建議您先從成功的測試回合移轉開始，再嘗試生產環境執行移轉。 透過測試回合匯入，您可以事先查看移轉的外觀、找出潛在問題，以及在進入生產執行之前取得經驗。

注意

  • 如果您需要針對集合重複完成的生產執行移轉，就像復原時一樣，請先連絡 Azure DevOps Services 客戶支援 ，再將另一個移轉排入佇列。
  • Azure 系統管理員可以防止使用者建立新的 Azure DevOps 組織。 如果開啟Microsoft Entra 租用戶原則，您的移轉將無法完成。 開始之前，請確認原則未設定，或執行移轉的使用者有例外狀況。 如需詳細資訊，請參閱 透過 Microsoft Entra 租用戶原則限制組織建立。
  • Azure DevOps Services 不支援每個管線保留原則，而且不會傳遞至裝載的版本。

復原計劃的考慮

對於執行最終生產回合的小組來說，常見的問題在於其復原計劃，如果移轉發生任何問題。 強烈建議執行測試，以確保您可以測試提供給 Azure DevOps 的數據遷移工具的移轉設定。

最終生產執行的復原相當簡單。 將移轉排入佇列之前，請先從 Azure DevOps Server 中斷連結小組專案集合，讓小組成員無法使用。 如果您需要復原生產執行，並讓內部部署伺服器重新上線，讓小組成員上線，您可以這麼做。 再次附加小組專案集合，並通知您的小組，他們繼續正常運作，而您的小組會重新群組以瞭解任何潛在的失敗。

然後，如果無法判斷原因，您可以連絡 Azure DevOps Services 客戶支援以取得了解失敗原因的說明。 如需詳細資訊，請參閱 疑難解答一文。 您可以從下列頁面 https://aka.ms/AzureDevOpsImportSupport開啟客戶支援票證。 請務必注意，如果問題需要產品群組工程師參與這些案例，將會在一般上班時間處理。

將小組專案集合從 Azure DevOps Server 中斷連結，以準備移轉。

在產生 SQL 資料庫的備份之前，數據遷移工具會要求從 Azure DevOps Server 完全中斷連結集合（而非 SQL）。 Azure DevOps Server 中的卸離程式會將儲存在集合資料庫外部的使用者身分識別資訊，並讓它可移植到新的伺服器，或在此案例中移至 Azure DevOps Services。

從 Azure DevOps Server 實例上的 Azure DevOps Server 管理控制台輕鬆卸離集合。 如需詳細資訊，請參閱 移動專案集合、中斷連結集合。

將移轉排入佇列

重要

繼續之前，請先確定您的集合在產生 DACPAC 檔案之前已 中斷連結 ，或將集合資料庫上傳至 SQL Azure VM。 如果您未完成此步驟，移轉會失敗。 如果您的移轉失敗，請參閱 解決移轉錯誤。

使用資料遷移工具的 匯 入命令啟動移轉。 移轉命令會採用移轉規格檔案作為輸入。 它會剖析檔案，以確保所提供的值有效，如果成功，它會將移轉至 Azure DevOps Services 的佇列。 移轉命令需要因特網連線，但不需要連線到您的 Azure DevOps Server 實例。

若要開始使用，請開啟 [命令提示字元] 視窗，並將目錄變更為數據遷移工具的路徑。 建議您檢閱工具所提供的說明文字。 執行下列命令以查看移轉命令的指引和說明：

Migrator import /help

將移轉排入佇列的命令具有下列結構：

Migrator import /importFile:{location of migration specification file}

下列範例顯示已完成的移轉命令：

Migrator import /importFile:C:\DataMigrationToolFiles\migration.json

驗證通過之後，請使用身分識別身分識別的身分識別登入 Microsoft Entra 識別碼，該身分識別與身分識別對應記錄檔建置的身分識別相同Microsoft Entra 租用戶的成員。 登入的用戶是匯入組織的擁有者。

注意

每個Microsoft Entra 租使用者限制為每 24 小時五個匯入。 僅針對此上限排入佇列計數的匯入。

當小組起始移轉時，會將電子郵件通知傳送給排入移轉佇列的使用者。 在移轉排入佇列大約 5 到 10 分鐘後，您的小組可以前往組織檢查狀態。 移轉完成後，您的小組會導向登入，並將電子郵件通知傳送給組織擁有者。

數據遷移工具會標幟移轉之前必須更正的錯誤。 本文說明您在準備移轉時可能收到的最常見警告和錯誤。 更正每個錯誤之後，請再次執行 移轉程式 validate 命令來驗證解決方式。

下一步

解決移轉錯誤