Provedení migrace testovacího spuštění

Váš tým je teď připravený zahájit proces spuštění testovacího běhu migrace a nakonec úplnou produkční migraci. V této fázi probereme poslední kroky pro vytvoření fronty migrace spolu s dalšími úkoly, které se obvykle objeví na konci projektu migrace.

Požadavky

Před zahájením migrace testovacího běhu dokončete fázi přípravy testovacího spuštění.

Ověření kolekce

Ověřte každou kolekci, kterou chcete migrovat do Azure DevOps Services. Krok ověření prozkoumá různé aspekty kolekce, včetně rozsahu, velikosti, kolace, identity a procesů.

Spusťte ověření pomocí nástroje pro migraci dat.

1. Stáhněte si nástroj pro migraci dat.

2. Zkopírujte soubor ZIP do jedné z vašich aplikačních vrstev Azure DevOps Serveru.

3. Rozbalte ho. Nástroj můžete spustit také z jiného počítače bez nainstalovaného Azure DevOps Serveru, pokud se počítač může připojit ke konfigurační databázi instance Azure DevOps Serveru.

4. Otevřete okno příkazového řádku na serveru a zadejte příkaz cd, který se má změnit do adresáře, ve kterém je uložený nástroj pro migraci dat. Chvíli si projděte obsah nápovědy pro nástroj.

   a. Pokud chcete zobrazit nápovědu a pokyny nejvyšší úrovně, spusťte následující příkaz.

    Migrator /help
   

   b. Zobrazte text nápovědy pro příkaz.

    Migrator validate /help 
   

5. Při prvním ověření kolekce by měl mít příkaz následující jednoduchou strukturu.

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

   Kde {name} zadáte název vašeho tenanta Microsoft Entra, například pro spuštění proti DefaultCollection a tenantu fabrikam , bude příkaz vypadat jako v následujícím příkladu.

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

6. Pokud chcete nástroj spustit z jiného počítače, než je Azure DevOps Server, potřebujete parametr /connectionString . Parametr připojovací řetězec odkazuje na konfigurační databázi Azure DevOps Serveru. Pokud například ověřený příkaz běží společností Fabrikam, bude příkaz vypadat takto.

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

   Důležité

   Nástroj pro migraci dat neupravuje žádná data ani struktury v kolekci. Čte kolekci pouze za účelem identifikace problémů.

7. Po dokončení ověření můžete zobrazit soubory protokolu a výsledky.

   

   Během ověřování se zobrazí upozornění, pokud některé kanály obsahují pravidla uchovávání jednotlivých kanálů. Azure DevOps Services používá model uchovávání informací založený na projektu a nepodporuje zásady uchovávání informací pro jednotlivé kanály. Pokud budete pokračovat v migraci, zásady se nepřenesou do hostované verze. Místo toho platí výchozí zásady uchovávání informací na úrovni projektu. Zachovejte buildy, které jsou pro vás důležité, abyste se vyhnuli jejich ztrátě.

Po dokončení všech ověření můžete přejít k dalšímu kroku procesu migrace. Pokud nástroj pro migraci dat označí nějaké chyby, opravte je před pokračováním. Pokyny k opravě chyb ověření najdete v tématu Řešení potíží s migrací a chybami migrace.

Import souborů protokolu

Když otevřete adresář protokolu, můžete si všimnout několika souborů protokolování.

Hlavní soubor protokolu má název DataMigrationTool.log. Obsahuje podrobnosti o všem, co bylo spuštěno. Abyste se mohli snadněji zaměřit na konkrétní oblasti, vygeneruje se protokol pro každou hlavní operaci ověření.

Pokud například TfsMigrator hlásí chybu v kroku Ověřování procesů projektu, můžete otevřít soubor ProjectProcessMap.log a zobrazit vše, co se pro tento krok spustilo, a nemusíte procházet celý protokol.

Zkontrolujte soubor TryMatchOobProcesses.log jenom v případě, že se pokoušíte migrovat procesy projektu, aby používaly zděděný model. Pokud nechcete používat zděděný model, můžete tyto chyby ignorovat, protože vám nebrání v importu do Azure DevOps Services. Další informace najdete ve fázi ověření migrace.

Generování souborů migrace

Nástroj pro migraci dat kolekci ověřil a vrací výsledek ověření všech kolekcí. Než provedete migraci kolekce offline, vygenerujte soubory migrace. Při spuštění prepare příkazu vygenerujete dva soubory migrace:

• IdentityMapLog.csv: Nastíní mapu identity mezi službou Active Directory a ID Microsoft Entra.
• migration.json: Vyžaduje, abyste vyplnili specifikaci migrace, kterou chcete použít k zahájení migrace.

Příkaz Připravit

Tento prepare příkaz vám pomůže generovat požadované soubory migrace. Tento příkaz v podstatě prohledá kolekci, aby našel seznam všech uživatelů, kteří naplní protokol mapování identit, IdentityMapLog.csv a pak se pokusí připojit k Microsoft Entra ID a najít shodu každé identity. K tomu potřebuje vaše společnost použít nástroj Microsoft Entra Connect (dříve označovaný jako nástroj synchronizace adresářů, nástroj Synchronizace adresářů nebo nástroj DirSync.exe).

Pokud je synchronizace adresářů nastavená, nástroj pro migraci dat by měl najít odpovídající identity a označit je jako aktivní. Pokud neexistují žádné shody, identita se v protokolu mapy identit označí jako Historická , takže musíte zjistit, proč uživatel není součástí synchronizace adresáře. Soubor specifikace migrace, migration.json, by se měl před migrací naplnit.

validate Na rozdíl od příkazu prepare vyžaduje připojení k internetu, protože se musí připojit k Microsoft Entra ID k naplnění souboru protokolu mapování identit. Pokud vaše instance Azure DevOps Serveru nemá přístup k internetu, spusťte nástroj z počítače, který to dělá. Pokud najdete počítač s intranetovým připojením k instanci Azure DevOps Serveru a připojením k internetu, můžete tento příkaz spustit. Nápovědu k prepare příkazu můžou získat spuštěním následujícího příkazu:

Migrator prepare /help

Součástí dokumentace nápovědy jsou pokyny a příklady pro spuštění Migrator příkazu ze samotné instance Azure DevOps Serveru a vzdáleného počítače. Pokud spouštíte příkaz z jedné z aplikačních vrstev instance Azure DevOps Serveru, měl by mít váš příkaz následující strukturu:

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"

Parametr connectionString je ukazatel na konfigurační databázi vaší instance Azure DevOps Serveru. Pokud například společnost Fabrikam spustí prepare příkaz, bude příkaz vypadat jako v následujícím příkladu:

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

Když nástroj pro migraci dat spustí prepare příkaz, spustí úplné ověření, které zajistí, že se od posledního úplného ověření v kolekci nic nezměnilo. Pokud se zjistí nějaké nové problémy, nevygenerují se žádné soubory migrace.

Krátce po spuštění příkazu se zobrazí přihlašovací okno Microsoft Entra. Přihlaste se pomocí identity, která patří do domény tenanta, která je zadaná v příkazu. Ujistěte se, že zadaný tenant Microsoft Entra je ten, se kterým chcete, aby vaše budoucí organizace podporovala. V našem příkladu Fabrikam uživatel zadá přihlašovací údaje, které jsou podobné následujícímu příkladu snímku obrazovky.

Důležité

Nepoužívejte testovacího tenanta Microsoft Entra pro testovací migraci a produkčního tenanta Microsoft Entra pro produkční běh. Použití testovacího tenanta Microsoft Entra může vést k problémům s migrací identit při spuštění produkčního prostředí s produkčním tenantem Microsoft Entra vaší organizace.

Po úspěšném spuštění prepare příkazu v nástroji pro migraci dat se v okně výsledků zobrazí sada protokolů a dva soubory migrace. V adresáři protokolu vyhledejte složku protokolů a dva soubory:

• migration.json je soubor specifikace migrace. Doporučujeme, abyste ho vyplnili nějakou dobu.
• IdentityMapLog.csv obsahuje vygenerované mapování služby Active Directory na identity Microsoft Entra. Před zahájením migrace ji zkontrolujte, jestli je dokončená.

Dva soubory jsou podrobněji popsány v dalších částech.

Soubor specifikace migrace

Specifikace migrace, migration.json, je soubor JSON, který poskytuje nastavení migrace. Obsahuje název požadované organizace, informace o účtu úložiště a další informace. Většina polí je automaticky vyplněná a některá pole vyžadují zadání před pokusem o migraci.

Zobrazená pole souboru migration.json a požadované akce jsou popsány v následující tabulce:

Pole	Popis	Požadovaná akce
Zdroj	Informace o umístěníach	Nevyžaduje se žádná akce. Zkontrolujte informace o akcích dílčích polí, které se mají sledovat.
Umístění	Sdílený přístupový podpisový klíč k účtu úložiště Azure, který je hostitelem balíčku aplikace datové vrstvy (DACPAC).	Nevyžaduje se žádná akce. Toto pole je popsáno v pozdějším kroku.
Soubory	Názvysouborůch	Nevyžaduje se žádná akce. Zkontrolujte informace o akcích dílčích polí, které se mají sledovat.
DACPAC	Soubor DACPAC, který zabalí databázi kolekce, která se má použít k přenesení dat během migrace.	Nevyžaduje se žádná akce. V pozdějším kroku vytvoříte tento soubor pomocí kolekce a pak ho nahrajete do účtu úložiště Azure. Aktualizujte soubor na základě názvu, který použijete při jeho vygenerování později v tomto procesu.
Cíl	Vlastnosti nové organizace, do které se má migrace provést.	Nevyžaduje se žádná akce. Zkontrolujte informace o akcích dílčích polí, které se mají sledovat.
Název	Název organizace, která se má vytvořit během migrace.	Zadejte název. Název můžete rychle změnit později po dokončení migrace. POZNÁMKA: Před spuštěním migrace nevytvořte organizaci s tímto názvem. Organizace se vytvoří jako součást procesu migrace.
ImportType	Typ migrace, kterou chcete spustit.	Nevyžaduje se žádná akce. V pozdějším kroku vyberte typ migrace, který chcete spustit.
Ověřovací data	Informace potřebné k řízení prostředí migrace	Nástroj pro migraci dat vygeneruje část ValidationData. Obsahuje informace, které vám pomůžou řídit prostředí migrace. Neupravujte hodnoty v této části, jinak by se nepodařilo spustit migraci.

Po dokončení předchozího procesu byste měli mít soubor, který vypadá jako v následujícím příkladu.

Na předchozím obrázku přidal plánovač migrace Fabrikam název organizace fabrikam-import a vybraný CUS (Central USA) jako zeměpisné umístění pro migraci. Ostatní hodnoty byly ponechány tak, jak je třeba upravit těsně před tím, než plánovač přenesl kolekci pro migraci do offline režimu.

Poznámka:

Importy testovacích běhů mají k názvu organizace automaticky připojenou možnost -dryrun, kterou můžete po migraci změnit.

Podporované oblasti Azure pro migraci

Služba Azure DevOps Services je dostupná v několika geografických umístěních Azure. Pro migraci se ale nepodporují všechna umístění, kde je dostupná služba Azure DevOps Services. Následující tabulka uvádí zeměpisné umístění Azure, která můžete vybrat pro migraci. Součástí je také hodnota, kterou musíte umístit do souboru specifikace migrace, aby se tato zeměpis cílila na migraci.

Zeměpisné umístění	Zeměpisné umístění Azure	Hodnota specifikace importu
USA	Centrální USA	CUS
Evropě	Západní Evropa	ZEU
Spojené království	Spojené království – jih	UkS
Austrálie	Austrálie – východ	Kolínská voda
Jižní Amerika	Brazílie – jih	SBR
Asie a Tichomoří	Indie – jih	MA
Asie a Tichomoří	Jihovýchodní Asie (Singapur)	SEA
Kanada	Střední Kanada	Kopie

Protokol mapování identit

Protokol mapování identit je stejně důležitý pro skutečná data, která migrujete do Azure DevOps Services. Při kontrole souboru je důležité pochopit, jak migrace identit funguje a co by mohlo mít potenciální výsledky. Když migrujete identitu, může se stát aktivní nebo historickou. Aktivní identity se můžou přihlásit ke službě Azure DevOps Services, ale historické identity ne.

Aktivní identity

Aktivní identity odkazují na identity uživatelů v Azure DevOps Services po migraci. V Azure DevOps Services jsou tyto identity licencované a zobrazují se jako uživatelé v organizaci. Identity jsou v souboru protokolu mapování identit označené jako aktivní ve sloupci Očekávaný stav importu.

Historické identity

Historické identity se mapují jako například ve sloupci Očekávaný stav importu v souboru protokolu mapování identit. Identity bez položky řádku v souboru se také stanou historickými. Příkladem identity bez zadání řádku může být zaměstnanec, který už ve společnosti nespravuje.

Na rozdíl od aktivních identit jsou historické identity:

• Po migraci nemáte přístup k organizaci.
• Nemáte licence.
• Nezobrazujte se jako uživatelé v organizaci. Vše, co přetrvává, je pojem názvu této identity v organizaci, aby bylo možné později vyhledat jeho historii. Doporučujeme používat historické identity pro uživatele, kteří už ve společnosti nefungují nebo nepotřebují další přístup k organizaci.

Poznámka:

Jakmile se identita naimportuje jako historická, nemůže být aktivní.

Vysvětlení souboru protokolu mapování identit

Soubor protokolu mapování identit je podobný příkladu uvedenému tady:

Sloupce v souboru protokolu mapování identit jsou popsané v následující tabulce:

Vy a váš správce Microsoft Entra musíte prozkoumat uživatele označené jako Nenalezené shody (zkontrolujte Synchronizaci ID Microsoft Entra), abyste pochopili, proč nejsou součástí vaší synchronizace Microsoft Entra Connect.

Sloupec	Popis
Active Directory: Uživatel (Azure DevOps Server)	Popisný zobrazovaný název používaný identitou na Azure DevOps Serveru. Tento název usnadňuje identifikaci uživatele, na který řádek v mapě odkazuje.
Active Directory: Identifikátor zabezpečení	Jedinečný identifikátor identity místní Active Directory na Azure DevOps Serveru. Tento sloupec slouží k identifikaci uživatelů v kolekci.
ID Microsoft Entra: Očekávaný uživatel importu (Azure DevOps Services)	Buď očekávaná přihlašovací adresa odpovídajícího uživatele, který brzy bude aktivní, nebo nebyla nalezena žádná shoda (zkontrolujte synchronizaci ID Microsoft Entra ID), která značí, že se identita ztratila během Synchronizace ID Microsoft Entra a importuje se jako historická.
Očekávaný stav importu	Očekávaný stav migrace uživatele: Buď aktivní, pokud je shoda mezi vaší službou Active Directory a ID Microsoft Entra, nebo historickým stavem, pokud se neshoda neshoduje.
Datum ověření	Čas posledního ověření protokolu mapování identit.

Při čtení souboru si všimněte, jestli je hodnota ve sloupci Očekávaný stav importu aktivní nebo historická. Aktivní označuje, že identita na tomto řádku se při migraci správně mapuje. Historické znamená, že identity se stanou historickými při migraci. Je důležité zkontrolovat vygenerovaný soubor mapování, abyste získali úplnost a správnost.

Důležité

Migrace selže, pokud dojde k významným změnám synchronizace ID zabezpečení microsoft Entra Connect mezi pokusy o migraci. Mezi testovací běhy můžete přidat nové uživatele a můžete provést opravy, abyste měli jistotu, že se dříve importované historické identity stanou aktivními. Nemůžete ale změnit existujícího uživatele, který byl dříve importován jako aktivní. Tím dojde k selhání migrace. Příkladem změny může být dokončení migrace testovacího spuštění, odstranění identity z vašeho ID Microsoft Entra, které bylo importováno aktivně, opětovné vytvoření nového uživatele v Microsoft Entra ID pro stejnou identitu a následné pokus o další migraci. V tomto případě se aktivní migrace identity pokusí mezi službou Active Directory a nově vytvořenou identitou Microsoft Entra, ale způsobí selhání migrace.

1. Zkontrolujte správně odpovídající identity. Existují všechny očekávané identity? Jsou uživatelé namapovaní na správnou identitu Microsoft Entra?

   Pokud je potřeba změnit nějaké hodnoty, obraťte se na správce Microsoft Entra a ověřte, jestli je identita místní Active Directory součástí synchronizace s ID Microsoft Entra a správně ji nastavila. Další informace naleznete v tématu Integrace místních identit s Microsoft Entra ID.

2. Dále zkontrolujte identity, které jsou označené jako historické. Toto označení znamená, že se nepodařilo najít odpovídající identitu Microsoft Entra, a to z některého z následujících důvodů:

   • Identita není nastavená pro synchronizaci mezi místní Active Directory a ID Microsoft Entra.
   • Identita ještě není vyplněná ve vašem ID Microsoft Entra (například existuje nový zaměstnanec).
   • Identita ve vaší instanci Microsoft Entra neexistuje.
   • Uživatel, který vlastní danou identitu, už ve společnosti nefunguje.

Pokud chcete vyřešit první tři důvody, nastavte zamýšlenou místní Active Directory identitu pro synchronizaci s ID Microsoft Entra. Další informace naleznete v tématu Integrace místních identit s Microsoft Entra ID. Musíte nastavit a spustit Microsoft Entra Connect pro identity, které se mají importovat jako aktivní ve službě Azure DevOps Services.

Čtvrtý důvod můžete ignorovat, protože zaměstnanci, kteří už nejsou ve společnosti, by se měli importovat jako historické.

Historické identity (malé týmy)

Poznámka:

Strategie migrace identit navržená v této části by měla být považována pouze malými týmy.

Pokud není služba Microsoft Entra Connect nakonfigurovaná, označí se všichni uživatelé v souboru protokolu mapy identit jako historické. Spuštění migrace tímto způsobem vede k importu všech uživatelů jako historických. Důrazně doporučujeme nakonfigurovat Microsoft Entra Connect , abyste měli jistotu, že vaši uživatelé budou importovaní jako aktivní.

Spuštění migrace se všemi historickými identitami má důsledky, které je potřeba pečlivě zvážit. Za příliš vysoké by se měly zvážit pouze týmy s několika uživateli a za které se náklady na nastavení služby Microsoft Entra Connect považují za příliš vysoké.

Pokud chcete všechny identity migrovat jako historické, postupujte podle kroků popsaných v dalších částech. Když zařadíte migraci do fronty, identita použitá k za frontě migrace se spustí do organizace jako vlastník organizace. Všichni ostatní uživatelé se importují jako historické. Vlastníci organizace pak můžou uživatele znovu přidat pomocí své identity Microsoft Entra. Přidaní uživatelé se považují za nové uživatele. Nevlastní žádnou z jejich historie a neexistuje způsob, jak tuto historii znovu použít k identitě Microsoft Entra. Uživatelé si ale stále můžou vyhledat svoji historii předmigrace vyhledáním jejich \<domain>\<Active Directory username>.

Nástroj pro migraci dat zobrazí upozornění, pokud zjistí kompletní scénář historických identit. Pokud se rozhodnete tuto cestu migrace snížit, musíte v nástroji souhlasit s omezeními.

Předplatná sady Visual Studio

Nástroj pro migraci dat nemůže při generování souboru protokolu mapování identit rozpoznat předplatná sady Visual Studio (dříve označovaná jako výhody MSDN). Místo toho doporučujeme po migraci použít funkci automatického upgradu licencí. Pokud jsou pracovní účty uživatelů propojené správně, azure DevOps Services automaticky použije výhody předplatného sady Visual Studio při prvním přihlášení po migraci. Za licence, které jsou přiřazené během migrace, se vám nikdy neúčtují žádné poplatky, abyste mohli bezpečně zpracovat předplatná.

Pokud se předplatná sady Visual Studio uživatelů automaticky neupgradují ve službě Azure DevOps Services, nemusíte opakovat migraci testovacího spuštění. Propojení předplatného sady Visual Studio probíhá mimo rozsah migrace. Pokud je jejich pracovní účet správně propojený před migrací nebo po migraci, licence uživatelů se při příštím přihlášení automaticky upgradují. Po úspěšném upgradu licencí se uživatelé při příštím spuštění migrace automaticky upgradují při prvním přihlášení k organizaci.

Příprava migrace

Teď máte všechno připravené ke spuštění při migraci testovacího běhu. Naplánujte prostoje s týmem, abyste mohli kolekci pro migraci převést do offline režimu. Pokud souhlasíte s časem spuštění migrace, nahrajte požadované prostředky, které jste vygenerovali, a kopii databáze do Azure. Příprava na migraci se skládá z následujících pěti kroků.

Krok 1: Přepojte kolekci do offline režimu a odpojte ji. Krok 2: Vygenerujte soubor DACPAC z kolekce, kterou budete migrovat.
Krok 3: Nahrajte soubor DACPAC a soubory migrace do účtu úložiště Azure.
Krok 4: Vygenerování tokenu SAS pro přístup k účtu úložiště
Krok 5: Dokončení specifikace migrace

Poznámka:

Před provedením produkční migrace důrazně doporučujeme dokončit migraci testovacího spuštění. Při testovacím spuštění můžete ověřit, že proces migrace funguje pro vaši kolekci a že neexistují žádné jedinečné datové obrazce, které by mohly způsobit selhání migrace do produkčního prostředí.

Krok 1: Odpojení kolekce

Odpojení kolekce je zásadním krokem v procesu migrace. Data identity pro kolekci se nacházejí v konfigurační databázi instance Azure DevOps Serveru, zatímco je kolekce připojená a online. Když je kolekce odpojená od instance Azure DevOps Serveru, vezme kopii těchto dat identity a zabalí je s kolekcí pro přenos. Bez těchto dat nejde spustit část migrace identity.

Tip

Doporučujeme, abyste kolekci odpojili, dokud se migrace nedokončí, protože neexistuje způsob, jak migrovat změny, ke kterým došlo během migrace. Znovu připojte kolekci po zálohování pro migraci, takže vás nezajímá, že máte nejnovější data pro tento typ migrace. Abyste se úplně vyhnuli offline času, můžete se také rozhodnout použít offline odpojení pro testovací běhy.

Je důležité zvážit náklady na výběr, aby se při testovacím běhu neúčtovaly žádné výpadky. Vyžaduje zálohování kolekce a konfigurační databáze, jejich obnovení v instanci SQL a následné vytvoření odpojené zálohy. Analýza nákladů může prokázat, že na konci je lepší trvat několik hodin výpadků, aby se přímo odpojilo zálohování.

Krok 2: Vygenerování souboru DACPAC

DaCPACs nabízejí rychlou a relativně snadnou metodu pro přesun kolekcí do Azure DevOps Services. Jakmile ale velikost databáze kolekce překročí určitou prahovou hodnotu, začnou se výhody používání daCPAC snižovat.

Poznámka:

Pokud nástroj pro migraci dat zobrazí upozornění, že nemůžete použít metodu DACPAC, musíte migraci provést pomocí metody virtuálního počítače SQL Azure. V takovém případě přeskočte kroky 2 až 5 a postupujte podle pokynů ve fázi přípravy testovacího běhu, části Migrace velkých kolekcí a pokračujte v určení typu migrace. Pokud nástroj pro migraci dat nezobrazuje upozornění, použijte metodu DACPAC popsanou v tomto kroku.

DACPAC je funkce SQL Serveru, která umožňuje zabalit databáze do jednoho souboru a nasadit je do jiných instancí SQL Serveru. Soubor DACPAC je také možné obnovit přímo do Azure DevOps Services, takže ho můžete použít jako metodu balení pro získání dat kolekce v cloudu.

Důležité

• Pokud používáte SqlPackage.exe, musíte k přípravě souboru DACPAC použít verzi rozhraní .NET Framework SqlPackage.exe. Instalační program MSI se musí použít k instalaci verze rozhraní .NET Framework SqlPackage.exe. Nepoužívejte rozhraní příkazového řádku dotnet ani .zip (Windows .NET 6) SqlPackage.exe, protože tyto verze můžou generovat řadiče DACPA, které nejsou kompatibilní se službou Azure DevOps Services.
• Verze 161 sqlPackage ve výchozím nastavení šifruje připojení k databázi a nemusí se připojit. Pokud se zobrazí chyba procesu přihlášení, přidejte ;Encrypt=False;TrustServerCertificate=True do připojovací řetězec příkazu SqlPackage.

Stáhněte a nainstalujte SqlPackage.exe pomocí nejnovějšího instalačního programu MSI z poznámky k verzi SqlPackage.

Po použití instalačního programu MSI SqlPackage.exe nainstaluje v cestě podobné %PROGRAMFILES%\Microsoft SQL Server\160\DAC\bin\.

Při generování souboru DACPAC mějte na paměti dvě aspekty: disk, na který je daCPAC uložený, a místo na disku na počítači, který generuje daCPAC. Chcete mít jistotu, že máte dostatek místa na disku k dokončení operace.

Při vytváření balíčku SqlPackage.exe dočasně ukládá data z kolekce do dočasného adresáře na jednotce C počítače, ze které iniciujete požadavek na balení.

Možná zjistíte, že jednotka C je příliš malá, aby podporovala vytvoření DACPAC. Velikost potřebného místa můžete odhadnout vyhledáním největší tabulky v databázi kolekce. DaCPACs se vytvoří po jedné tabulce. Maximální prostor pro spuštění generování je zhruba ekvivalentní velikosti největší tabulky v databázi kolekce. Pokud uložíte vygenerovaný daCPAC na jednotku C, zvažte velikost databáze kolekce, jak je hlášeno v souboru DataMigrationTool.log ze spuštění ověření.

Soubor DataMigrationTool.log poskytuje seznam největších tabulek v kolekci při každém spuštění příkazu. Příklad velikostí tabulek pro kolekci najdete v následujícím výstupu. Porovnejte velikost největší tabulky s volným místem na jednotce, která je hostitelem dočasného adresáře.

Důležité

Než budete pokračovat v generování souboru DACPAC, ujistěte se, že je vaše kolekce odpojená.

[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

Ujistěte se, že jednotka, která je hostitelem dočasného adresáře, má alespoň tolik volného místa. Pokud ne, musíte dočasný adresář přesměrovat nastavením proměnné prostředí.

SET TEMP={location on disk}

Dalším aspektem je uložení dat DACPAC. Umístění uloženého umístění na vzdálené vzdálené disky může vést k delší době generování. Pokud je místně k dispozici rychlá jednotka, jako je jednotka SSD (Solid-State Drive), doporučujeme jednotku cílit jako umístění pro uložení DACPAC. V opačném případě je vždy rychlejší používat disk, který je na počítači, ve kterém se nachází databáze kolekce, a ne na vzdálené jednotce.

Teď, když jste identifikovali cílové umístění pro DACPAC a ujistili jste se, že máte dostatek místa, je čas vygenerovat soubor DACPAC.

Otevřete okno příkazového řádku a přejděte do SqlPackage.exe umístění. Pokud chcete vygenerovat daCPAC, nahraďte zástupné hodnoty požadovanými hodnotami a spusťte následující příkaz:

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

• Zdroj dat: Instance SQL Serveru, která je hostitelem vaší databáze kolekce Azure DevOps Serveru.
• Počáteční katalog: Název databáze kolekce.
• targetFile: Umístění na disku a název souboru DACPAC.

V následujícím příkladu je zobrazený příkaz generování DACPAC, který běží na samotné datové vrstvě Azure DevOps Serveru:

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

Výstupem příkazu je soubor DACPAC vygenerovaný z databáze kolekce Foo s názvem Foo.dacpac.

Konfigurace kolekce pro migraci

Po obnovení databáze kolekce na virtuálním počítači Azure nakonfigurujte přihlášení SQL tak, aby se služba Azure DevOps Services mohla připojit k databázi pro migraci dat. Toto přihlášení umožňuje přístup jen pro čtení k jedné databázi.

Začněte tak, že na virtuálním počítači otevřete APLIKACI SQL Server Management Studio a pak otevřete nové okno dotazu pro databázi, kterou chcete importovat.

Nastavte obnovení databáze na jednoduché:

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

Vytvořte pro databázi přihlášení SQL a přiřaďte ho k přihlášení 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>'

V našem příkladu Fabrikam by dva příkazy SQL vypadaly jako v následujícím příkladu:

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'

Poznámka:

Na virtuálním počítači povolte režim ověřování SQL Serveru a Windows v sadě SQL Server Management Studio. Pokud režim ověřování nepovolíte, migrace selže.

Konfigurace souboru specifikace migrace pro cílení na virtuální počítač

Aktualizujte soubor specifikace migrace tak, aby obsahoval informace o tom, jak se připojit k instanci SQL Serveru. Otevřete soubor specifikace migrace a proveďte následující aktualizace.

1. Odeberte parametr DACPAC ze zdrojového objektu souborů.

   Specifikace migrace před změnou se zobrazí v následujícím kódu.

   

   Specifikace migrace po provedení změny se zobrazí v následujícím kódu.

   

2. Vyplňte požadované parametry a do souboru specifikace přidejte následující objekt vlastností.

   "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" 
   }
   

Po použití změn bude specifikace migrace vypadat jako v následujícím příkladu.

Vaše specifikace migrace je teď nakonfigurovaná tak, aby k migraci používala virtuální počítač SQL Azure. Pokračujte zbývajícími kroky přípravy migrace do Azure DevOps Services. Po dokončení migrace nezapomeňte odstranit přihlášení k SQL nebo otočit heslo. Microsoft po dokončení migrace nezachová přihlašovací údaje.

Krok 3: Nahrání souboru DACPAC

Poznámka:

Pokud používáte metodu virtuálního počítače Azure SQL, musíte zadat jenom připojovací řetězec. Nemusíte nahrávat žádné soubory a tento krok můžete přeskočit.

Váš DACPAC se musí umístit do kontejneru úložiště Azure, což může být existující kontejner nebo kontejner vytvořený speciálně pro vaše úsilí o migraci. Je důležité zajistit, aby se kontejner vytvořil ve správných geografických umístěních.

Azure DevOps Services je k dispozici v několika geografických umístěních. Při importu do těchto umístění je důležité správně umístit data, aby se migrace úspěšně spustila. Vaše data musí být umístěná ve stejném zeměpisném umístění, do kterého importujete. Umístění dat kamkoli jinam způsobí, že se migrace nedá spustit. Následující tabulka uvádí přijatelné zeměpisné umístění pro vytvoření účtu úložiště a nahrání dat.

Požadovaná geografická poloha migrace	Zeměpisné umístění účtu úložiště
Centrální USA	Centrální USA
Západní Evropa	Západní Evropa
Spojené království	Spojené království – jih
Austrálie – východ	Austrálie – východ
Brazílie – jih	Brazílie – jih
Jižní Indie	Jižní Indie
Střední Kanada	Střední Kanada
Asie a Tichomoří (Singapur)	Asie a Tichomoří (Singapur)

Přestože je služba Azure DevOps Services dostupná v několika geografických umístěních v USA, přijímá nové služby Azure DevOps Services pouze centrální USA umístění. V tuto chvíli nemůžete migrovat data do jiných umístění Azure v USA.

Vytvořte kontejner objektů blob z webu Azure Portal. Po vytvoření kontejneru nahrajte soubor DACPAC kolekce.

Po dokončení migrace odstraňte kontejner objektů blob a doprovodný účet úložiště pomocí nástrojů, jako je AzCopy nebo jakýkoli jiný nástroj Průzkumníka úložiště Azure, jako je Průzkumník služby Azure Storage.

Poznámka:

Pokud je váš soubor DACPAC větší než 10 GB, doporučujeme použít AzCopy. AzCopy má podporu vícevláknového nahrávání pro rychlejší nahrávání.

Krok 4: Vygenerování tokenu SAS

Token sdíleného přístupového podpisu (SAS) poskytuje delegovaný přístup k prostředkům v účtu úložiště. Token vám umožňuje udělit Microsoftu nejnižší úroveň oprávnění vyžadovanou pro přístup k datům při provádění migrace.

Tokeny SAS můžete vygenerovat pomocí webu Azure Portal. Z hlediska zabezpečení doporučujeme provádět následující úlohy:

1. Jako oprávnění pro token SAS vyberte jen čtení a výpis . Nejsou vyžadována žádná další oprávnění.
2. Nastavte dobu vypršení platnosti až sedm dní do budoucnosti.
3. Omezte přístup pouze k IP adresám Azure DevOps Services.
4. Klíč SAS považujete za tajný klíč. Nezachovejte klíč v nezabezpečeném umístění, protože uděluje přístup pro čtení a seznam ke všem datům uloženým v kontejneru.

Krok 5: Dokončení specifikace migrace

Dříve v procesu jste částečně vyplnili soubor specifikace migrace, který se označuje jako migration.json. V tomto okamžiku máte dostatek informací k dokončení všech zbývajících polí s výjimkou typu migrace. Typ migrace se probírá později v části migrace.

V souboru specifikace migration.json v části Zdroj vyplňte následující pole.

• Umístění: Vložte klíč SAS, který jste vygenerovali ze skriptu, a zkopírujte ho v předchozím kroku.
• Dacpac: Ujistěte se, že soubor, včetně přípony souboru .dacpac , má stejný název jako soubor DACPAC, který jste nahráli do účtu úložiště.

Konečný soubor specifikace migrace by měl vypadat jako v následujícím příkladu.

Určení typu migrace

Importy lze zařadit do fronty buď jako testovací běh, nebo jako produkční běh. Parametr ImportType určuje typ migrace:

• TestRun: Použijte testovací běh pro účely testování. Systém odstraní testovací běhy po 45 dnech.
• ProductionRun: Použijte produkční běh, když chcete zachovat výslednou migraci a po dokončení migrace používat organizaci na plný úvazek ve službě Azure DevOps Services.

Tip

Vždy doporučujeme, abyste nejprve dokončili migraci testovacího spuštění.

Testovací spuštění organizací

Organizace testovacích běhů pomáhají týmům otestovat migraci kolekcí. Před spuštěním produkční migrace je nutné odstranit všechny dokončené organizace testovacích běhů. Všechny organizace testovacích běhů mají omezenou existenci a po nastaveném časovém období se automaticky odstraní. Informace o tom, kdy se organizace odstraní, se zahrnou do e-mailu o úspěchu, který byste měli obdržet po dokončení migrace. Nezapomeňte si odpovídajícím způsobem poznamenat toto datum a plán.

Organizace testovacího spuštění mají před odstraněním 45 dnů. Po zadaném časovém období se organizace testovacího běhu odstraní. Importy testovacích běhů můžete opakovat tolikrát, kolikrát potřebujete, než provedete produkční migraci.

Odstranění testovacích běhů

Před pokusem o nové spuštění odstraňte všechna předchozí testovací spuštění. Až bude váš tým připravený k provedení produkční migrace, musíte organizaci testovacího spuštění odstranit ručně. Než budete moct spustit druhou migraci testovacího běhu nebo konečnou produkční migraci, nezapomeňte odstranit všechny předchozí organizace Azure DevOps Services, které jste vytvořili v předchozím testovacím běhu. Další informace najdete v tématu Odstranění organizace.

Tip

Volitelné informace, které uživateli pomůžou být úspěšnější, se očekává, že migrace testovacího běhu, která následuje po prvním, bude trvat delší dobu potřebnou k vyčištění prostředků z předchozích testovacích běhů.

Po odstranění nebo přejmenování může trvat až hodinu, než se název organizace zpřístupní. Další informace najdete v článku Úlohy po migraci.

Pokud narazíte na nějaké problémy s migrací, přečtěte si téma Řešení potíží s migrací a chybami migrace.

Spuštění migrace

Váš tým je teď připravený zahájit proces spuštění migrace. Než se pokusíte o migraci do produkčního prostředí, doporučujeme začít úspěšnou migrací testovacího běhu. Při importech testovacích běhů můžete předem zjistit, jak migrace vypadá, identifikovat potenciální problémy a získat zkušenosti před zahájením provozu v produkčním prostředí.

Poznámka:

• Pokud potřebujete zopakovat dokončenou migraci spuštěnou v produkčním prostředí pro kolekci, jako v případě vrácení zpět, kontaktujte zákaznickou podporu Azure DevOps Services, než zařadíte jinou migraci do fronty.

• Správci Azure můžou uživatelům zabránit v vytváření nových organizací Azure DevOps. Pokud je zapnutá zásada tenanta Microsoft Entra, migrace se nedokončí. Než začnete, ověřte, že zásada není nastavená nebo že pro uživatele, který provádí migraci, existuje výjimka. Další informace najdete v tématu Omezení vytváření organizace prostřednictvím zásad tenanta Microsoft Entra.
• Azure DevOps Services nepodporuje zásady uchovávání informací pro jednotlivé kanály a nepřenesou se do hostované verze.

Důležité informace o plánech vrácení zpět

Běžným problémem pro týmy, které provádějí finální produkční běh, je plán vrácení zpět, pokud se s migrací něco nepovede. Důrazně doporučujeme provést testovací běh, abyste měli jistotu, že můžete otestovat nastavení migrace, která zadáte nástroji pro migraci dat pro Azure DevOps.

Vrácení zpět pro finální produkční běh je poměrně jednoduché. Před frontou migrace odpojte kolekci týmových projektů z Azure DevOps Serveru, aby byla pro členy týmu nedostupná. Pokud z nějakého důvodu potřebujete vrátit produkční běh a přenést místní server zpět do online režimu pro členy týmu, můžete to udělat. Připojte kolekci týmových projektů znovu místně a informujte svůj tým, že bude dál normálně fungovat, zatímco se tým znovu seskupí, aby porozuměl potenciálním selháním.

Pokud nemůžete zjistit příčinu, můžete kontaktovat zákaznickou podporu Azure DevOps Services a zjistit příčinu selhání. Další informace najdete v článku Řešení potíží. Lístky zákaznické podpory lze otevřít na následující stránce https://aka.ms/AzureDevOpsImportSupport. Je důležité si uvědomit, že pokud problém vyžaduje, aby technici produktové skupiny tyto případy zapojili, budou během běžné pracovní doby zpracovávány.

Odpojte kolekci týmových projektů z Azure DevOps Serveru a připravte ji na migraci.

Před vygenerováním zálohy databáze SQL nástroj pro migraci dat vyžaduje, aby se kolekce úplně odpojila od Azure DevOps Serveru (ne SQL). Proces odpojení v Azure DevOps Serveru přenáší informace o identitě uživatele, které jsou uložené mimo databázi kolekce, a umožňuje přenositelný přechod na nový server nebo v tomto případě do Azure DevOps Services.

Odpojení kolekce se snadno provádí z konzoly pro správu Serveru Azure DevOps v instanci Azure DevOps Serveru. Další informace naleznete v tématu Přesunutí kolekce projektů, odpojení kolekce.

Zařadíte migraci do fronty

Důležité

Než budete pokračovat, ujistěte se, že se vaše kolekce před vygenerováním souboru DACPAC odpojila nebo nahrála databázi kolekce na virtuální počítač SQL Azure. Pokud tento krok nedokončíte, migrace selže. Pokud migrace selže, přečtěte si téma Řešení chyb migrace.

Spusťte migraci pomocí importu nástroje pro migraci dat. Příkaz migrace jako vstup vezme soubor specifikace migrace. Parsuje soubor, aby se zajistilo, že zadané hodnoty jsou platné a v případě úspěchu zařadí migraci do služby Azure DevOps Services. Příkaz pro migraci vyžaduje připojení k internetu, ale nevyžaduje připojení k vaší instanci Azure DevOps Serveru.

Začněte tak, že otevřete okno příkazového řádku a změníte adresáře na cestu k nástroji pro migraci dat. Doporučujeme, abyste si zkontrolovali text nápovědy, který je součástí nástroje. Spuštěním následujícího příkazu zobrazte pokyny a nápovědu k příkazu migrace:

Migrator import /help

Příkaz pro vytvoření fronty migrace má následující strukturu:

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

Následující příklad ukazuje dokončený příkaz migrace:

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

Po úspěšném ověření se přihlaste k MICROSOFT Entra ID s identitou, která je členem stejného tenanta Microsoft Entra jako soubor protokolu mapování identit. Přihlášený uživatel je vlastníkem importované organizace.

Poznámka:

Každý tenant Microsoft Entra je omezený na pět importů za 24 hodin. Do tohoto limitu se započítávají pouze importy, které jsou zařazené do fronty.

Když váš tým zahájí migraci, odešle se uživateli, který migraci zařadil do fronty, e-mailové oznámení. Přibližně 5 až 10 minut po zařazení migrace do fronty může váš tým přejít do organizace a zkontrolovat stav. Po dokončení migrace se váš tým přesměruje k přihlášení a odešle se e-mailové oznámení vlastníkovi organizace.

Nástroj pro migraci dat označuje chyby, které je potřeba před migrací opravit. Tento článek popisuje nejběžnější upozornění a chyby, které se můžou zobrazit při přípravě na migraci. Po opravě každé chyby znovu spusťte příkaz pro ověření migrace a ověřte řešení.

Další kroky

Řešení chyb migrace

Související články

• Přehled migrace
• Úkoly po migraci