Sdílet prostřednictvím

Ověření a příprava serverového prostředí na migraci

  • Článek

Ověření zahrnuje přípravu upgradovaného prostředí Azure DevOps Serveru pro migraci. Tento článek vám pomůže při řešení běžných problémů. Pokud nedošlo k žádným chybám a všechny kontroly ověření proběhly úspěšně, je kolekce týmových projektů připravená a můžete přejít k další fázi. Projděte si soubory protokolu a vyhledejte případné chyby, pokud nebyly všechny kontroly úspěšné.

Diagram zvýrazněné fáze Ověření v sedmi fázích migrace

Požadavky

Stáhněte si nejnovější nástroj pro migraci dat.

Seznámení s typy ověřování procesů

Nástroj pro migraci dat během ověřování určuje model cílového procesu pro každý projekt. Každému projektu v kolekci automaticky přiřadí jeden z následujících dvou procesních modelů:

  • Model zděděného procesu: Pokud byl projekt vytvořen pomocí šablony procesu Agile, Scrum nebo Capability Maturity Model Integration (CMMI) a nebyl nikdy přizpůsoben.
  • Model hostovaného procesu XML: Pokud se zdá, že je proces projektu přizpůsobený. Přizpůsobený proces obsahuje vlastní pole, typy pracovních položek nebo jiné typy přizpůsobení.

Pokud je hostovaný proces XML cílovým modelem procesu, nástroj pro migraci dat ověří, jestli je možné migrovat vlastní nastavení. Nástroj pro migraci dat během ověřování vygeneruje dva soubory:

  • DataMigrationTool.log: Obsahuje sadu chyb ověření procesu nalezených v kolekci. Opravte všechny zjištěné chyby procesu a pokračujte v migraci.
  • TryMatchOobProcesses.log: Vypíše pro každý projekt model cílového procesu – dědičnost nebo hostovaný XML. U projektů, které jsou nastavené tak, aby cílily na model hostovaného procesu XML, vysvětluje, proč se považují za přizpůsobené. Tyto chyby nemusíte opravovat, ale poskytují pokyny, co dělat v případě, že chcete migrovat na model procesu dědičnosti. Jakmile se kolekce migruje, můžete projekt migrovat do modelu procesu dědičnosti.

Ověření kolekce týmových projektů

Vzhledem k tomu, že každá kolekce týmových projektů odpovídá vlastní databázi SQL, proces ověřování prozkoumá různé aspekty kolekce, včetně:

  • Velikost databáze kolekce
  • Kolace databáze SQL
  • Identity uživatelů v kolekci
  • Přizpůsobení šablon (proces)

K zahájení ověřování použijte nástroj pro migraci. Doporučujeme spustit nástroj pro migraci z jednoho ze serverů aplikační vrstvy (AT) ve vašem prostředí Azure DevOps Serveru.

V případě konkrétních možností příkazového řádku požádejte o text nápovědy pomocí následujícího příkazu:

	Migrator validate /help

Nejběžnější způsob, jak zahájit ověřování, je zadat adresu URL kolekce týmových projektů s následující strukturou:

	Migrator validate /collection:http://localhost:8080/tfs/DefaultCollection

Zobrazeníupozorněních

Po dokončení nástroje pro migraci vygeneruje soubory protokolů a výsledky zobrazené na obrazovce příkazového řádku. Pokud nedojde k žádným chybám a všechny kontroly ověření projdou, kolekce týmových projektů je připravená pro další fázi. V případě selhání kontrol ověření zkontrolujte soubory protokolu a identifikujte chyby a pak je vyřešte.

Zaměřte se na Migrator.log soubor, který obsahuje základní podrobnosti o kontrolách ověření a pomáhá zachovat přizpůsobení. Ostatní soubory odpovídají konkrétním chybám ověření na základě jejich názvů. Vyhledejte řetězec "Validation - Starting validation of project 1" (Ověření – zahájení ověření projektu 1). Každý projekt se ověří. Prohledejte všechny projekty a vyhledejte všechny řádky, které obsahují předponu [Error...

Obsahuje TryMatchOobProcesses.log také chyby související s projekty, které používají procesy OOB (Out-of-Box) (například Agile, Scrum nebo CMMI). Pokud projekt používá proces OOB bez přizpůsobení, projekt je součástí zděděného modelu. Důležité je, že chyby v tomto souboru nebrání procesu migrace.

Snímek obrazovky se souborem DataMigrationTool.log vygenerovaným nástrojem pro migraci dat

Seznam chyb ověření najdete v tématu Řešení chyb ověření. Pro každou chybu ověření jsme zadali číslo chyby, popis a metodu, která se má vyřešit. V protokolech ověření se můžou objevit různé typy chyb. Vyhledejte pomoc od vašeho vytrénovaného partnera DevOps, konzultačních služeb Microsoftu nebo podpory Microsoft Premier Support pro řešení zjištěných chyb.

Řešení chyb šablon procesů

Hlavní chyby, které jsme zjistili, jsou problémy se šablonou procesu. Tyto problémy vycházejí z zastaralých týmových projektů, které neobsahují nejnovější funkce Azure DevOps Serveru nebo nepodporovaná přizpůsobení služby Azure DevOps Services. Azure DevOps Services ale podporuje celou řadu přizpůsobení a ověřování označuje pouze ty, které vyžadují premigraci řešení. Nástroj pro migraci dat provádí komplexní kontrolu kompatibility šablon pro Azure DevOps Services, ale některé úpravy můžou být nezbytné.

  • Přizpůsobené šablony procesů nebo zastaralé šablony můžou během migrace způsobit chyby ověření procesu.
  • Pokud používáte proces OOB Agile, Scrum nebo CMMI, zkontrolujte TryMatchOobProcesses.log chyby. Projekty bez chyb se mapuje na procesy OOB.
  • Některá přizpůsobení nefungují v Azure DevOps Services. Projděte si seznam podporovaných přizpůsobení.
  • U projektů používajících starší šablony spusťte Průvodce konfigurací funkcí a aktualizujte šablony s nedávnými funkcemi a snižte počet chyb.
  • Ujistěte se witadmin , že je na počítači, kde opravujete chyby procesu, k dispozici. Je nezbytné provádět změny šablon procesů.
  • Před pokusem o migraci by měla být pravidla pro pravidla zakomentována nebo odebrána ze šablony procesu. Tato pravidla se podporují ve službě Azure DevOps Service, ale v rámci procesu migrace se nepodporují. Po migraci kolekce můžete tato pravidla přidat zpět do šablony procesu.

Při řešení chyb procesu zvažte následující nástroje:

  • Využijte nástroj příkazového řádku witadmin.exe, který je součástí instalací sady Visual Studio. Podrobné technické dokumentace k řešení těchto chyb najdete na tomto odkazu.
  • Automatizace exportu šablon procesů pro každý týmový projekt pomocí příkazu nástroje pro nezdokumentovaný nástroj pro migraci: Migrator ověří /collection:http://localhost:8080/tfs/DefaultCollection /SaveProcesses.
  • Prozkoumejte správce týmových projektů TFS na GitHubu (odkaz). Umožňuje porovnat týmové projekty se známými šablonami procesů, včetně předefinovaných šablon.

Chyby opravíte tak, že změníte syntaxi XML a změny použijete zpět do projektu.

Tip

Místo použití nástrojů TFS Power Tools doporučujeme xml upravit ručně.

Pokud chcete získat šablonu procesu z projektu, přidejte /SaveProcesses parametr při spuštění příkazu Nástroje pro migraci dat.

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

Tento příkaz extrahuje XML z projektu a umístí ho do stejné složky jako protokoly. Extrahujte soubory ZIP do místního počítače, abyste mohli soubory upravovat.

Teď opravte KÓD XML. K určení chyb jednotlivých projektů použijte protokoly ze souboru DataMigrationTool.log.

Snímek obrazovky se souborem protokolování procesu vygenerovaným nástrojem pro migraci dat

Některé chyby vyžadují, abyste použili witadmin changefield příkaz. Nejběžnějším příkladem je změna názvu pole. Pokud si chcete ušetřit čas, doporučujeme spustit příkaz witadmin changefield a pak znovu spustit nástroj pro migraci dat. Tím znovu exportujete XML s opravenými názvy. V opačném případě opravte pole také ručně v syntaxi XML.

Jakmile provedete opravu, použijte změny zpět na Azure DevOps Server. V závislosti na provedených změnách musíte spustit jeden nebo více příkazů witadmin. Vytvořili jsme skript PowerShellu pro automatizaci tohoto procesu. Skript obsahuje všechny příkazy witadmin potřebné k potvrzení celého procesu.

Skripty můžete získat ve skriptech přizpůsobení procesu. Použijte skript import/ConformProject.ps1.

.\conformproject.ps1 "<collection url>" "<project name>" "<process template folder>"

Po dokončení skriptu spusťte nástroj pro migraci dat znovu a ověřte kolekci. Postupujte podle kroků 1 až 3, dokud nástroj pro migraci dat negeneruje žádné další chyby ověření.

Snímek obrazovky s procesem souladu s projektem v PowerShellu

Tip

Pokud s XML a witadmin teprve začínáte, doporučujeme, abyste najednou udělali jednu opravu a pak se shodili. Pokračujte v této smyčce, dokud se nevyřeší všechny chyby.

Aktualizace na systémový proces

Pokud jste začali se starší verzí Azure DevOps Serveru, vaše projekty pravděpodobně používají starší šablonu procesu. Pokud se tyto projekty neaktualizovaly pomocí Průvodce konfigurací funkcí, nástroj pro migraci dat zjistí chyby procesu. Ve výjimečných případech nemusí ani průvodce vyřešit staré problémy související s procesem.

Může se zobrazit některá z následujících ukázkových chybových zpráv:

Invalid process template: WorkItem Tracking\Process\ProcessConfiguration.xml:: TF402571: Required element PortfolioBacklog is missing from Process Configuration.
Invalid process template: WorkItem Tracking\Process\ProcessConfiguration.xml:: TF402571: Required element BugWorkItems is missing from Process Configuration.
Invalid process template: WorkItem Tracking\Process\ProcessConfiguration.xml:: TF402571: Required element FeedbackRequestWorkItems is missing from Process Configuration.
Invalid process template: WorkItem Tracking\Process\ProcessConfiguration.xml:: TF402571: Required element FeedbackResponseWorkItems is missing from Process Configuration.
Invalid process template: WorkItem Tracking\Process\ProcessConfiguration.xml:: TF402574: ProcessConfiguration doesn't specify required TypeField Team.
Invalid process template: WorkItem Tracking\Process\ProcessConfiguration.xml:: TF402574: ProcessConfiguration doesn't specify required TypeField RemainingWork.
Invalid process template: WorkItem Tracking\Process\ProcessConfiguration.xml:: TF402574: ProcessConfiguration doesn't specify required TypeField Order.
Invalid process template: WorkItem Tracking\Process\ProcessConfiguration.xml:: TF402574: ProcessConfiguration doesn't specify required TypeField Effort.
Invalid process template: WorkItem Tracking\Process\ProcessConfiguration.xml:: TF402574: ProcessConfiguration doesn't specify required TypeField Activity.
Invalid process template: WorkItem Tracking\Process\ProcessConfiguration.xml:: TF402574: ProcessConfiguration doesn't specify required TypeField ApplicationStartInformation.
Invalid process template: WorkItem Tracking\Process\ProcessConfiguration.xml:: TF402574: ProcessConfiguration doesn't specify required TypeField ApplicationLaunchInstructions.
Invalid process template: WorkItem Tracking\Process\ProcessConfiguration.xml:: TF402574: ProcessConfiguration doesn't specify required TypeField ApplicationType.
Invalid process template: WorkItem Tracking\Process\ProcessConfiguration.xml:: TF400572: The Project Process Settings must be configured for this feature to be used.

Pokud jste projekt nepřizpůsobili (například přidaná pole, typy pracovních položek atd.), oprava těchto chyb je jednoduchá. Pokud jste ale proces přizpůsobili, tento přístup nestačí. Šablony procesů je potřeba upravit ručně, abyste zachovali vlastní nastavení před přepsáním.

Při sladění procesu proveďte následující kroky pro každý projekt:

  1. Identifikujte počáteční proces, se kterým váš projekt začal (Scrum, Agile nebo CMMI).
  2. Navštivte skripty pro přizpůsobení procesů na GitHubu a stáhněte si úložiště.
  3. Zaměřte se na obsah ve složce Migrace.
  4. Pomocí následujícího ConformProject.ps1 skriptu můžete sladit projekt podle vašeho výběru s procesem agilního systému. Tato akce aktualizuje celý projekt tak, aby byl agilní.
.\ConformProject.ps1 "<collection url>" "<project name>" "c:\process-customization-scripts\import\agile"

Běžné chyby ověřování

VS402841: Pole X v typu Pracovní položka Chyba má syncnamechanges=false, ale obsahuje pravidla, která tvoří pole identity. Pole identity musí mít syncnamechanges=true. Aktualizujte šablonu procesu tak, aby zahrnovala tuto změnu.

Ve službě Azure DevOps Services jsme přidali pravidlo, aby každé pole identity muselo mít syncnamechanges=true atribut. V Azure DevOps Serveru se toto pravidlo nepoužije. Nástroj pro migraci dat proto tento problém identifikuje. Provedení této změny v místním azure DevOps Serveru nezpůsobuje žádné škody.

Spusťte příkaz witadmin changefield . Syntaxe příkazu vypadá jako v následujícím příkladu.

witadmin changefield /collection:http://AdventureWorksServer:8080/tfs/DefaultCollection /n:fieldname /syncnamechanges:true

Další informace o příkazu witadmin changefield naleznete v tématu Správa polí pracovních položek.

TF402556: Aby bylo možné správně definovat id iterace pole System.IterationId, musíte ho pojmenovat a nastavit jeho typ na Celé číslo.

Tato chyba je často spojena se zastaralými šablonami procesů. Pokud ho chcete vyřešit, můžete spustit Průvodce konfigurací funkcí pro každý projekt. Případně můžete spustit následující příkaz, který proces automatizuje.

witadmin changefield /collection:http://AdventureWorksServer:8080/tfs/DefaultCollection /n:fieldname /name:newname

TF402571: V konfiguraci procesu chybí požadovaný element BugWorkItems.

K této chybě obvykle dochází, když se nějaký čas neaktualizoval proces. Pokud ho chcete opravit, spusťte Průvodce konfigurací funkcí pro každý projekt.

TF402564: Definovali jste globální seznamy XX. Je povoleno pouze 64

Azure DevOps Services nativně podporuje 64 globálních seznamů. K této chybě obvykle dochází, když existuje velký počet kanálů sestavení, protože každý nový kanál vytvoří globální seznam s názvem Builds - TeamProjectName. Pokud chcete tuto chybu vyřešit, odeberte všechny zastaralé globální seznamy.

Opakování kontrol ověření

V každé iteraci vyřešte chyby a proveďte ověřovací kontroly k jejich vyřešení, jak je označuje soubory protokolu ověření. Tento cyklus přetrvává, dokud nebudou opraveny všechny chyby a obdržíte potvrzení, že kontroly ověření kolekce jsou úspěšné.

Další kroky

Příprava na testovací běh