Share via

移轉概觀

  • 文章

從 Azure DevOps Server 移至 Azure DevOps Services 是想要利用雲端式共同作業、延展性和增強功能的組織的重要步驟。 在此概觀中，我們會探索將寶貴數據從內部部署 Azure DevOps Server 傳輸到雲端式 Azure DevOps Services 的選項。

如需內部部署 Azure DevOps Server 與雲端式 Azure DevOps Services 之間主要差異的資訊，請參閱 比較 Azure DevOps Services 與 Azure DevOps Server - Azure DevOps。

無論您選取的移轉選項為何，建議您判斷最重要的資產，例如原始程式碼和工作專案。 您應該考慮您的數據大小、組織複雜性，並確定在實際移轉之前有足夠的時間進行測試執行，以順利且成功的轉換。

移轉的方法

請務必根據採用 Azure DevOps Services 的特定動機，評估每個移轉方法的優缺點。 正確的策略取決於您獨特的內容和需求。

選項。 建議的案例 限制
1：手動移轉 用於較小的專案或特定數據子集。 並非所有的數據都可以以完全逼真度進行移轉，而且受限於節流。 此移轉不支援移轉 XML 範本，因此您必須將進程範本重新建立為繼承的範本。
2：Azure DevOps 數據遷移工具 用於具有不同數據類型和複雜結構的中型到大規模移轉。 您只能將一個 Azure DevOps Server 集合「隨即轉移」到一個新的 Azure DevOps Services 組織，而不需要修改。 如需詳細資訊，請參閱 一節。
3：以 API 為基礎的移轉 為具有獨特移轉需求或自動化需求的組織提供彈性和自定義功能。 可能會發生低精確度、數據遺失和標識碼變更。 如需詳細資訊，請參閱 一節。

選項 1：手動移轉

例如，當 Microsoft 的 Azure DevOps 小組選擇從 Azure DevOps Server 移至 Azure DevOps Services 時，我們也決定從 Team Foundation 版本控制 （TFVC） 移至 Git。 移轉需要大量規劃，但當我們移轉時，我們會使用 TFVC 來源的「小費」版本建立新的 Git 存放庫，並在 Azure DevOps Server 中留下我們的歷程記錄。 我們也移動了作用中的工作專案，並留下所有舊的 Bug、已完成用戶劇本和工作等等。

手動移轉程序

  1. 識別您需要移轉的最重要資產 - 通常是原始程式碼、工作專案或兩者。 Azure DevOps Server 中的其他資產 - 建置管線、測試計劃等等 - 較難手動移轉。
  2. 識別進行轉換的適當時間。
  3. 準備目標組織。 建立您需要的組織和小組專案、布建使用者等等。
  4. 遷移您的資料。
  5. 請考慮將來源 Azure DevOps Server 部署設定為唯讀。 您可以透過下列方式執行此動作：
    • 調整專案層級許可權：在專案層級將所有使用者或群組的許可權設定為唯讀，您可以在 [項目設定] 中 修改安全性角色來執行此動作。
    • 修改存放庫設定：針對每個存放庫，您可以變更設定使其變成只讀，這牽涉到調整每個使用者或群組的許可權，只允許讀取動作。
    • 使用內建安全組：利用內建安全組更有效率地管理許可權。 您可以將使用者指派給「讀取者」之類的群組，以提供唯讀存取權。
    • 腳本許可權變更：如果您有許多專案或存放庫，您可能需要編寫腳本。 您可以使用 Azure CLI DevOps 擴充功能 來列出所有許可權，並視需要加以更新。
    • 停用存放庫功能：停用存放庫的存取權，包括組建和提取要求，但會使用警告讓存放庫保持可探索。 移至 [項目設定>>存放庫] 存放庫，然後在 [停用存放庫] 旁，將切換開關移至 [開啟]。

選項 2：Azure DevOps 移轉工具

Azure DevOps 數據遷移工具是由 Microsoft 提供的一組公用程式，可協助將數據從 Azure DevOps Server 移轉至 Azure DevOps Services。 這些工具提供簡化的方法，可移轉各種成品，包括原始程式碼、工作專案、測試案例和其他專案相關數據。

在起始移轉程式之前，這些工具可以執行預先移轉分析，以評估來源環境的整備程度，並找出可能影響移轉的潛在問題或相依性。 評估整備程度，以便事先規劃和減輕潛在挑戰。

移轉工具限制

此工具可讓您「隨即轉移」一個 Azure DevOps Server 集合至一個新的 Azure DevOps Service 組織，但基於下列原因而不需要修改：

  • 數據完整性和一致性：
    • 當您移轉數據時，維護完整性和一致性非常重要。 在移轉期間允許修改可能會導致數據損毀或不一致。
    • 此工具可確保數據在傳輸過程中保持不變，將錯誤的風險降到最低。
  • 來源資料保留：
    • 移轉工具旨在忠實地復寫目標環境中的源數據。
    • 修改可能會改變原始數據，這可能會導致移轉的數據與源數據之間的差異。
  • 可預測的行為：
    • 藉由限制修改，此工具可確保在移轉期間可預測的行為。
    • 用戶可以依賴一致的結果，而不會發生非預期的變更。
  • 移轉焦點，而非轉換：
    • 移轉工具的主要目的是將數據從一個位置移到另一個位置。
    • 數據轉換（例如修改值）通常會在移轉后個別處理。

您可以清除移轉前後不需要的數據。

移轉工具程式

  1. 完成必要條件，例如將 Azure DevOps Server 更新為兩個最新版本之一。
  2. 驗證您想要移至 Azure DevOps Services 的每個集合。
  3. 產生移轉檔案。
  4. 準備移轉執行的所有專案。
  5. 執行測試回合。
  6. 執行移轉。
  7. 確認您的使用者和數據已移轉，且集合如預期般運作。

選項3：以 API 為基礎的移轉

如果基於某些原因，您無法使用資料遷移工具，但仍想要比 選項 2 更高的精確度移轉，您可以從使用公用 API 來移動資料的各種工具中選擇。

API 型移轉限制

API 型移轉發生下列限制：

  • 低精確度移轉：
    • 限制：API 型工具提供比手動複製更高的逼真度，但仍相對較低的逼真度。
    • 含意：雖然這些工具提供一些逼真度，但它們不會保留數據的所有層面。
      • 範例：其中沒有任何保留 TFVC 變更集的原始日期（Team Foundation 版本控制）。
      • 許多人也不會保留工作專案修訂的變更日期。
  • 資料遺失和識別碼變更：
    • 限制：在移轉期間，工具會重新執行工作項目變更、TFVC 變更集、套件摘要和管線成品。
    • 含意：此程式可能會導致數據遺失、產生新的標識符，以及改變建立、修改和關閉日期。
      • 範例：系結至特定日期的歷程記錄內容可能會遺失，因而影響報告和可追蹤性。

API 型移轉程式

一般而言，只有在手動復本以外的額外逼真度很重要時，我們才建議使用此方法。 如果您決定採用這種方法，您可以考慮僱用具有一或多個工具經驗的顧問，並在最終移轉之前進行測試移轉。

許多組織只需要其工作子集的精確度非常高的移轉。 新的工作可能會直接在 Azure DevOps Services 中啟動。 其他工作，使用較不嚴格的逼真度需求，可以使用其中一種方法來移轉。

支援的進程模型

Azure DevOps Services 支援下列程式模型：

根據預設，Azure DevOps Services 中會 關閉 託管的 XML。 只有在您在 Azure DevOps Server 中自定義專案時，才會在移轉期間開啟託管的 XML 程式模型。 一旦項目位於託管 XML 上，您就可以 將它升級為移轉後繼承的 XML。

主要原則

移轉至 Azure DevOps Services 時，請記住下列重要原則和限制：

  • Azure DevOps Services 僅限英文：Azure DevOps Server 支援多種語言，但目前 Azure DevOps Services 僅支援英文。 如果您的集合使用非英文或過去使用非英文，而且您在升級期間將語言轉換成英文，則無法使用數據遷移工具。
  • 繼承：從敏捷式、Scrum 或 CMMI 程式範本建立且從未自定義的專案，會在移轉後位於繼承程式模型上。
  • 裝載的 XML：具有自定義專案的任何項目都會使用託管的 XML 進程模型。
  • 每個自定義專案的程式：雖然 Azure DevOps Services 允許專案共用程式，但數據遷移工具會為每個自定義小組專案建立託管的 XML 程式。 例如，如果您有 30 個自定義專案，您有 30 個要管理的託管 XML 程式。 如果您想要進一步自定義所有項目的託管 XML 程式，則必須個別更新每個託管的 XML 進程。
  • 程序驗證：數據遷移工具的程式驗證會偵測每個專案的目標進程模型。 在移轉之前，您必須修正裝載 XML 專案的任何進程驗證錯誤。 您可能想要考慮更新項目的程式，以符合我們的其中一個程式（Agile、Scrum 或 CMMI），以利用繼承程式模型。 在我們的檔中深入瞭解程式驗證類型。

資源

下一步

開始使用 Azure DevOps 移轉工具