Procesy ověřování a importu

Azure DevOps Services | Azure DevOps Server 2022 – Azure DevOps Server 2019

Tento článek vás provede přípravou potřebnou k dokončení importu do Azure DevOps Services. Pokud během procesu narazíte na chyby, přečtěte si téma Řešení potíží s chybami importu a migrace.

Požadavky

• Musíte nastavit tenanta Microsoft Entra, jak je popsáno v Microsoft Entra Připojení Sync: Proveďte změnu výchozí konfigurace. Nástroj pro migraci dat nastaví odkaz na vašeho tenanta Microsoft Entra, když se v rámci procesu importu vytvoří vaše organizace Azure DevOps Services. Když synchronizujete místní Active Directory s ID Microsoft Entra, členové týmu můžou k ověření použít stejné přihlašovací údaje a vaši správci azure DevOps Services můžou k nastavení oprávnění v organizaci Azure DevOps Services používat skupiny Active Directory. K nastavení synchronizace použijte technologii Microsoft Entra Připojení.
• Než začnete s úlohami importu, zkontrolujte, že používáte podporovanou verzi Azure DevOps Serveru.
• K pokroku při importu doporučujeme použít podrobný průvodce migrací. Průvodce odkazuje na technickou dokumentaci, nástroje a osvědčené postupy.

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. Stažení nástroje

2. Zkopírování souboru ZIP do jedné z 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ěřování kolekce ji pojďme zachovat jednoduchou. Příkaz by měl mít následující strukturu:

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

   Kde {name} zadáte název vašeho tenanta Microsoft Entra, například spuštění proti DefaultCollection a tenantovi fabrikam , bude tento příkaz vypadat jako v 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 spustí 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 importu. Pokud nástroj pro migraci dat označí nějaké chyby, před pokračováním je opravte. Pokyny k opravě chyb ověření najdete v tématu Řešení potíží s chybami importu a 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 importovat procesy projektu, aby používal 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.

Generování souborů importu

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

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

Příkaz Připravit

Tento prepare příkaz vám pomůže generovat požadované soubory importu. 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 Připojení (dříve označovaný jako nástroj Synchronizace adresářů, nástroj Synchronizace adresářů nebo nástroj DirSync.exe).

Pokud je nastavená synchronizace adresářů, 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 importu, import.json, by se měl před importem naplnit.

validate Na rozdíl od příkazu preparevyž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é importované soubory.

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í import a produkčního tenanta Microsoft Entra pro produkční běh. Při použití testovacího tenanta Microsoft Entra může dojít k problémům s importem 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 importu. V adresáři protokolu vyhledejte složku protokolů a dva soubory:

• import.json je soubor specifikace importu. Doporučujeme, abyste ho vyplnili nějakou dobu.
• IdentityMapLog.csv obsahuje vygenerované mapování služby Active Directory na identity Microsoft Entra. Než začnete s importem, zkontrolujte jeho úplnost.

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

Soubor specifikace importu

Specifikace importu, import.json, je soubor JSON, který poskytuje nastavení importu. 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 import.

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

Pole	Popis	Požadovaná akce
Source	Informace o umístění a názvech zdrojových datových souborů, které se používají k importu.	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ázvy souborů obsahujících data importu.	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 importu.	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 mají importovat.	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 importu.	Zadejte název. Název můžete rychle změnit později po dokončení importu. POZNÁMKA: Před spuštěním importu nevytvořte organizaci s tímto názvem. Organizace se vytvoří jako součást procesu importu.
ImportType	Typ importu, který chcete spustit.	Nevyžaduje se žádná akce. V pozdějším kroku vyberte typ importu, který chcete spustit.
Ověřovací data	Informace potřebné k řízení prostředí importu	Nástroj pro migraci dat vygeneruje část ValidationData. Obsahuje informace, které vám pomůžou řídit prostředí importu. Neupravujte hodnoty v tomto oddílu nebo se nepodařilo spustit import.

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č importu Fabrikam název organizace fabrikam-import a vybraný CUS (Centrální USA) jako zeměpisné umístění pro import. 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 suchého spuštění mají automaticky připojenou ke konci názvu organizace -dryrun, který můžete po importu změnit.

Podporovaná geografická umístění Azure pro import

Služba Azure DevOps Services je dostupná v několika geografických umístěních Azure. Pro import 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 import. Součástí je také hodnota, kterou musíte umístit do souboru specifikace importu, aby se tato zeměpisná oblast cílila pro import.

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	EAU
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 import identit funguje a co by mohlo mít potenciální výsledky. Když importujete 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 importu. 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:

Abyste pochopili, proč nejsou součástí vaší služby Microsoft Entra Připojení Sync, musíte vy a váš správce Microsoft Entra prošetřit uživatele označené jako Nenalezené shody (kontrola Synchronizace ID Microsoft Entra).

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)	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 během synchronizace ID Microsoft Entra nenašla a importuje se jako historická.
Očekávaný stav importu	Očekávaný stav importu uživatele: Buď aktivní , pokud existuje shoda mezi vaší službou Active Directory a ID Microsoft Entra, nebo historickým stavem, pokud se neshoda nenajde.
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 importu správně mapuje. Historické znamená, že identity se při importu stanou historickými. Je důležité zkontrolovat vygenerovaný soubor mapování, abyste získali úplnost a správnost.

Důležité

Import selže, pokud dojde k významným změnám v synchronizaci ID zabezpečení microsoft Entra Připojení mezi pokusy o import. Mezi suchá spuštění můžete přidávat nové uživatele a můžete provádět opravy, které zajistí, že se dříve importované historické identity stanou aktivními. Změna existujícího uživatele, který byl dříve importován jako aktivní, se v současné době nepodporuje. Tím dojde k selhání importu. Příkladem změny může být dokončení importu suché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ší import. V tomto případě se aktivní import identity pokusí mezi službou Active Directory a nově vytvořenou identitou Microsoft Entra, ale způsobí selhání importu.

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 některé hodnoty změnit, 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 je správně nastavená. 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 Připojení pro import identit 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 importu identit navržená v této části by měla být považována pouze za malé týmy.

Pokud není nakonfigurovaná služba Microsoft Entra Připojení, označí se všichni uživatelé v souboru protokolu mapy identit jako historické. Spuštění importu tímto způsobem vede k importu všech uživatelů jako historických. Důrazně doporučujeme nakonfigurovat Microsoft Entra Připojení, abyste zajistili, že se uživatelé importují jako aktivní.

Spuštění importu se všemi historickými identitami má důsledky, které je potřeba pečlivě zvážit. Náklady na nastavení microsoft Entra Připojení se považují za příliš vysoké, pouze týmy s několika uživateli.

Pokud chcete importovat všechny identity jako historické, postupujte podle kroků popsaných v dalších částech. Když zařadíte import do fronty, identita použitá k za frontě importu se zařadí 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é ale stále můžou vyhledat svoji historii předběžného importu vyhledáním uživatelského jména> ve službě <><Active Directory domény.

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 importu 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 importu. Za licence, které se při importu přiřazují, se vám nikdy neúčtují žádné poplatky, takže je pak můžete bezpečně zpracovat.

Pokud se předplatná sady Visual Studio uživatelů automaticky neupgradují ve službě Azure DevOps Services, nemusíte opakovat suchý import. Propojení předplatného sady Visual Studio probíhá mimo rozsah importu. Pokud je jejich pracovní účet správně propojený před importem nebo po jeho importu, 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í importu automaticky upgradují při prvním přihlášení do organizace.

Příprava na import

Teď máte všechno připravené ke spuštění při importu. 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í importu, nahrajte požadované prostředky, které jste vygenerovali, a kopii databáze do Azure. Příprava na import se skládá z následujících pěti kroků.

Krok 1: Přepojte kolekci do offline režimu a odpojte ji.

Limit velikosti kolekce pro metodu DACPAC je 150 GB. Pokud nástroj pro migraci dat zobrazí upozornění, že nemůžete použít metodu DACPAC, musíte provést import 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ů uvedených v části Import velkých kolekcí a pak pokračujte v určení typu importu.

Krok 2: Vygenerujte soubor DACPAC z kolekce, kterou chcete importovat.
Krok 3: Nahrajte soubor DACPAC a importujte soubory 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 importu

Poznámka:

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

Krok 1: Odpojení kolekce

Odpojení kolekce je zásadním krokem v procesu importu. 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 nelze spustit část importu identity. Doporučujeme ponechat kolekci odpojenou, dokud se import nedokončí, protože neexistuje způsob, jak importovat změny, ke kterým došlo během importu.

Pro suchý import (test) doporučujeme znovu připojit kolekci po zálohování k importu, takže vás nezajímá, že máte nejnovější data pro tento typ importu. Abyste se úplně vyhnuli offline času, můžete se také rozhodnout použít offline odpojení pro suchá spuštění.

Je důležité zvážit náklady na volbu, aby se pro suchý běh neúčtovaly nulové 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 provést import pomocí metody virtuálního počítače SQL Azure, která je součástí importu velkých kolekcí.

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í 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 import

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 import 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 [Foo] SET RECOVERY SIMPLE;

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

Poznámka:

Nezapomeňte na virtuálním počítači povolit režim ověřování SQL Serveru a Windows v sadě SQL Server Management Studio. Pokud režim ověřování nepovolíte, import se nezdaří.

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

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

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

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

   

   Specifikace importu po změně 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 importu vypadat jako v následujícím příkladu.

Vaše specifikace importu je teď nakonfigurovaná tak, aby k importu používala virtuální počítač SQL Azure. Pokračujte zbývajícími kroky přípravy pro import do Azure DevOps Services. Po dokončení importu nezapomeňte odstranit přihlášení k SQL nebo otočit heslo. Microsoft po dokončení importu 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 zajistilo úspěšné spuštění importu. 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 import nejde 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é umístění importu	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 importovat data do jiných umístění Azure v USA.

Kontejner objektů blob můžete vytvořit na webu Azure Portal. Po vytvoření kontejneru nahrajte soubor DACPAC kolekce.

Po dokončení importu 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ě. Tento token vám umožní udělit Microsoftu nejnižší úroveň oprávnění vyžadovanou pro přístup k datům při provádění importu.

Tokeny SAS je možné vygenerovat pomocí webu Azure Portal. Z hlediska zabezpečení doporučujeme:

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. Umístěte token SAS do zabezpečeného umístění.

Krok 5: Dokončení specifikace importu

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

V souboru specifikace import.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 importu by měl vypadat jako v následujícím příkladu.

Omezení přístupu pouze k IP adresám Azure DevOps Services

Další informace najdete v tématu Omezení přístupu pouze k IP adresám Azure DevOps Services.

Možnost 1: Použití značek služeb

Připojení ze všech geografických umístění Azure DevOps Services můžete snadno povolit přidáním azuredevopsznačky služby do skupin zabezpečení sítě nebo bran firewall prostřednictvím portálu nebo prostřednictvím kódu programu.

Možnost 2: Použití iplistu

IpList Pomocí příkazu získáte seznam IP adres, kterým je potřeba udělit přístup, aby bylo možné povolit připojení z konkrétního geografického umístění Azure DevOps Services.

Součástí dokumentace nápovědy jsou pokyny a příklady pro spuštění nástroje Migrator 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 IpList /collection:{CollectionURI} /tenantDomainName:{name} /region:{region}

Seznam IP adres můžete přidat do skupin zabezpečení sítě nebo bran firewall prostřednictvím portálu nebo programově.

Určení typu importu

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

• DryRun: Použijte suchý běh pro testovací účely. Systém odstraní suchá spuštění po 21 dnech.
• ProductionRun: Pokud chcete zachovat výsledný import a po dokončení importu používat celou organizaci ve službě Azure DevOps Services, použijte produkční běh.

Tip

Vždy doporučujeme nejprve dokončit import suchého spuštění.

Organizace s suchým provozem

Importy suchých běhů pomáhají týmům otestovat migraci kolekcí. Očekává se, že organizace nezůstanou navždy, ale na krátkou dobu budou existovat. Před spuštěním produkční migrace je třeba odstranit všechny dokončené organizace s suchým spuštěním. Všechny organizace s suchým provozem 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í importu. Nezapomeňte si odpovídajícím způsobem poznamenat toto datum a plán.

Většina suchých organizací má před odstraněním 15 dní. Organizace s suchým provozem můžou mít také 21denní vypršení platnosti, pokud v době importu má více než 100 uživatelů základní nebo vyšší licenci. Po uplynutí zadaného časového období se organizace suchého spuštění odstraní. Importy suchého spuštění můžete opakovat tolikrát, kolikrát potřebujete, než provedete produkční migraci. Před pokusem o nové spuštění musíte odstranit všechna předchozí suchá spuštění. Až bude váš tým připravený k provedení produkční migrace, musíte ručně odstranit suchou organizaci.

Další informace o aktivitách po importu najdete v článku o následném importu.

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

Spuštění importu

Váš tým je teď připravený zahájit proces spuštění importu. Než se pokusíte o import do produkčního prostředí, doporučujeme začít úspěšným importem suchého spuštění. S importy suchých běhů můžete předem zjistit, jak vypadá import, 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čený import produkčního spuštění pro kolekci, jako v případě vrácení zpět, obraťte se před frontou na zákaznickou podporu azure DevOps Services, než zařadíte do fronty další import.

• 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, import 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 při importu něco nepovede. Důrazně doporučujeme provést suchý běh, abyste měli jistotu, že můžete otestovat nastavení importu, která poskytnete nástroji pro migraci dat pro Azure DevOps.

Vrácení zpět pro finální produkční běh je poměrně jednoduché. Než import zařadíte do fronty, odpojíte kolekci týmových projektů od Azure DevOps Serveru, což členům týmu znepřístupní. 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.

Zařadí import 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, import selže. V případě selhání importu najdete v tématu Řešení potíží s chybami importu a migrace.

Spusťte import pomocí příkazu importu nástroje pro migraci dat. Příkaz importu přebírá jako vstup soubor specifikace importu. Parsuje soubor, aby se zajistilo, že zadané hodnoty jsou platné a v případě úspěchu zařadí import do služby Azure DevOps Services. Příkaz importu 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 importu:

Migrator import /help

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

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

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

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

Po úspěšném ověření se zobrazí výzva, abyste se přihlásili k ID Microsoft Entra. Je důležité se přihlásit pomocí identity, 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í import, odešle se uživateli, který import zařadil do fronty, e-mailové oznámení. Přibližně 5 až 10 minut po zařazení importu do fronty může váš tým přejít do organizace a zkontrolovat stav. Po dokončení importu se váš tým přesměruje k přihlášení a odešle se e-mailové oznámení vlastníkovi organizace.

Související články

• Možnosti migrace
• Po importu