Gör testkörningsmigrering
Ditt team är nu redo att påbörja processen med att starta en testkörning av migreringen och slutligen en fullständig produktionsmigrering. I den här fasen diskuterar vi de sista stegen för att köa en migrering utöver andra uppgifter som vanligtvis kommer upp i slutet av migreringsprojektet.
Förutsättningar
Slutför fasen Förbered testkörning innan du påbörjar en testkörningsmigrering.
Verifiera en samling
Verifiera varje samling som du vill migrera till Azure DevOps Services. Valideringssteget undersöker olika aspekter av din samling, inklusive, men inte begränsat till, storlek, sortering, identitet och processer.
Kör valideringen med hjälp av datamigreringsverktyget.
Kopiera zip-filen till en av dina Azure DevOps Server-programnivåer.
Packa upp filen. Du kan också köra verktyget från en annan dator utan att Azure DevOps Server är installerat, så länge datorn kan ansluta till konfigurationsdatabasen för Azure DevOps Server-instansen.
Öppna ett kommandotolkfönster på servern och ange ett cd-kommando för att ändra till katalogen där datamigreringsverktyget lagras. Ta en stund att granska hjälpinnehållet för verktyget.
a. Om du vill visa hjälp och vägledning på den översta nivån kör du följande kommando.
Migrator /helpb. Visa hjälptexten för kommandot.
Migrator validate /helpSom första gången du verifierar en samling bör kommandot ha följande enkla struktur.
Migrator validate /collection:{collection URL} /tenantDomainName:{name} /region:{region}Där
{name}anger namnet på din Microsoft Entra-klientorganisation, till exempel för att köras mot DefaultCollection och fabrikam-klientorganisationen , ser kommandot ut som i följande exempel.Migrator validate /collection:http://localhost:8080/DefaultCollection /tenantDomainName:fabrikam.OnMicrosoft.com /region:{region}Om du vill köra verktyget från en annan dator än Azure DevOps Server behöver du parametern /connectionString . Parametern anslutningssträng pekar på din Azure DevOps Server-konfigurationsdatabas. Om det verifierade kommandot till exempel körs av Fabrikam-företaget ser kommandot ut så här.
Migrator validate /collection:http://fabrikam:8080/DefaultCollection /tenantDomainName:fabrikam.OnMicrosoft.com /region:{region} /connectionString:"Data Source=fabrikam;Initial Catalog=Configuration;Integrated Security=True"Viktigt!
Datamigreringsverktyget redigerar inte några data eller strukturer i samlingen. Den läser endast samlingen för att identifiera problem.
När valideringen är klar kan du visa loggfilerna och resultaten.
Under valideringen får du en varning om vissa av dina pipelines innehåller kvarhållningsregler per pipeline. Azure DevOps Services använder en projektbaserad kvarhållningsmodell och stöder inte kvarhållningsprinciper per pipeline. Om du fortsätter med migreringen överförs inte principerna till den värdbaserade versionen. I stället gäller standardprinciperna för kvarhållning på projektnivå. Behåll byggen som är viktiga för dig för att undvika förlust.
När alla valideringar har godkänts kan du gå vidare till nästa steg i migreringsprocessen. Om datamigreringsverktyget flaggar några fel korrigerar du dem innan du fortsätter. Vägledning om hur du korrigerar valideringsfel finns i Felsöka migrerings- och migreringsfel.
Importera loggfiler
När du öppnar loggkatalogen kanske du ser flera loggningsfiler.
Huvudloggfilen heter DataMigrationTool.log. Den innehåller information om allt som kördes. För att göra det enklare för dig att fokusera på specifika områden genereras en logg för varje större valideringsåtgärd.
Om TfsMigrator till exempel rapporterar ett fel i steget "Validera projektprocesser" kan du öppna filen ProjectProcessMap.log för att visa allt som kördes för det steget i stället för att behöva bläddra igenom hela loggen.
Granska endast TryMatchOobProcesses.log-filen om du försöker migrera dina projektprocesser för att använda den ärvda modellen. Om du inte vill använda den ärvda modellen kan du ignorera dessa fel eftersom de inte hindrar dig från att importera till Azure DevOps Services. Mer information finns i Validera migreringsfasen.
Generera migreringsfiler
Datamigreringsverktyget verifierade samlingen och returnerar ett resultat av "Alla samlingsvalideringar har godkänts". Innan du tar en samling offline för att migrera den genererar du migreringsfilerna. När du kör prepare kommandot genererar du två migreringsfiler:
- IdentityMapLog.csv: Beskriver din identitetskarta mellan Active Directory och Microsoft Entra ID.
- migration.json: Kräver att du fyller i migreringsspecifikationen som du vill använda för att starta migreringen.
Kommandot Förbered
Kommandot prepare hjälper till med att generera nödvändiga migreringsfiler. I princip söker det här kommandot igenom samlingen för att hitta en lista över alla användare som ska fylla i identitetskartans logg, IdentityMapLog.csv, och försöker sedan ansluta till Microsoft Entra-ID för att hitta varje identitets matchning. För att göra det måste företaget använda Microsoft Entra Connect-verktyget (kallades tidigare katalogsynkroniseringsverktyget, verktyget Katalogsynkronisering eller DirSync.exe).
Om katalogsynkronisering har konfigurerats bör datamigreringsverktyget hitta matchande identiteter och markera dem som Aktiva. Om det inte finns några matchningar markeras identiteten som Historisk i identitetsmappningsloggen, så du måste undersöka varför användaren inte ingår i katalogsynkroniseringen. Migreringsspecifikationsfilen, migration.json, bör fyllas i före migreringen.
validate Till skillnad från kommandot prepare kräver en Internetanslutning, eftersom den måste ansluta till Microsoft Entra-ID för att fylla i identitetsmappningsloggfilen. Om din Azure DevOps Server-instans inte har internetåtkomst kör du verktyget från en dator som gör det. Så länge du kan hitta en dator med en intranätanslutning till din Azure DevOps Server-instans och en Internetanslutning kan du köra det här kommandot. Om du vill ha hjälp med prepare kommandot kör du följande kommando:
Migrator prepare /help
I hjälpdokumentationen finns instruktioner och exempel för att köra Migrator kommandot från själva Azure DevOps Server-instansen och en fjärrdator. Om du kör kommandot från någon av Azure DevOps Server-instansens programnivåer bör kommandot ha följande struktur:
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"
Parametern connectionString är en pekare till konfigurationsdatabasen för din Azure DevOps Server-instans. Om fabrikam-företaget till exempel kör prepare kommandot ser kommandot ut som i följande exempel:
Migrator prepare /collection:http://fabrikam:8080/DefaultCollection /tenantDomainName:fabrikam.OnMicrosoft.com /region:{region} /connectionString:"Data Source=fabrikam;Initial Catalog=Configuration;Integrated Security=True"
När datamigreringsverktyget kör prepare kommandot körs en fullständig validering för att säkerställa att inget har ändrats med din samling sedan den senaste fullständiga valideringen. Om nya problem identifieras genereras inga migreringsfiler.
Kort efter att kommandot börjar köras visas ett Microsoft Entra-inloggningsfönster. Logga in med en identitet som tillhör klientdomänen, som anges i kommandot . Kontrollera att den angivna Microsoft Entra-klientorganisationen är den som du vill att din framtida organisation ska säkerhetskopieras med. I vårt Fabrikam-exempel anger en användare autentiseringsuppgifter som liknar följande skärmbild.
Viktigt!
Använd inte en Microsoft Entra-testklient för en testmigrering och din Microsoft Entra-produktionsklient för produktionskörningen. Om du använder en testklientorganisation för Microsoft Entra kan det leda till problem med identitetsmigrering när du påbörjar produktionskörningen med organisationens Microsoft Entra-klientorganisation för produktion.
När du kör prepare kommandot i datamigreringsverktyget visar resultatfönstret en uppsättning loggar och två migreringsfiler. Leta reda på en loggmapp och två filer i loggkatalogen:
- migration.json är migreringsspecifikationsfilen. Vi rekommenderar att du tar dig tid att fylla i den.
- IdentityMapLog.csv innehåller den genererade mappningen av Active Directory till Microsoft Entra-identiteter. Granska den för fullständighet innan du startar en migrering.
De två filerna beskrivs mer detaljerat i nästa avsnitt.
Migreringsspecifikationsfilen
Migreringsspecifikationen, migration.json, är en JSON-fil som tillhandahåller migreringsinställningar. Den innehåller önskat organisationsnamn, lagringskontoinformation och annan information. De flesta fält fylls i automatiskt och vissa fält kräver dina indata innan du försöker migrera.
Den migration.json filens fält som visas och nödvändiga åtgärder beskrivs i följande tabell:
| Fält | beskrivning | Nödvändig åtgärd |
|---|---|---|
| Källa | Information om platsen och namnen på källdatafilerna som används för migrering. | Ingen åtgärd krävs. Granska informationen för de underfältsåtgärder som ska följas. |
| Plats | Signaturnyckeln för delad åtkomst till azure-lagringskontot som är värd för programpaketet på datanivå (DACPAC). | Ingen åtgärd krävs. Det här fältet beskrivs i ett senare steg. |
| Filer | Namnen på filerna som innehåller migreringsdata. | Ingen åtgärd krävs. Granska informationen för de underfältsåtgärder som ska följas. |
| DACPAC | En DACPAC-fil som paketar samlingsdatabasen som ska användas för att hämta data under migreringen. | Ingen åtgärd krävs. I ett senare steg skapar du den här filen med hjälp av din samling och laddar sedan upp den till ett Azure Storage-konto. Uppdatera filen baserat på det namn du använder när du genererar den senare i den här processen. |
| Mål | Egenskaper för den nya organisationen att migrera till. | Ingen åtgärd krävs. Granska informationen för de underfältsåtgärder som ska följas. |
| Name | Namnet på den organisation som ska skapas under migreringen. | Ange ett namn. Namnet kan snabbt ändras senare efter att migreringen har slutförts. Obs! Skapa inte en organisation med det här namnet innan du kör migreringen. Organisationen skapas som en del av migreringsprocessen. |
| ImportType | Den typ av migrering som du vill köra. | Ingen åtgärd krävs. I ett senare steg väljer du vilken typ av migrering som ska köras. |
| Valideringsdata | Information som behövs för att underlätta migreringen. | Datamigreringsverktyget genererar avsnittet "ValidationData". Den innehåller information som hjälper dig att förbättra migreringsupplevelsen. Redigera inte värdena i det här avsnittet eller så kan migreringen misslyckas med att starta. |
När du har slutfört föregående process bör du ha en fil som ser ut som i följande exempel.
I föregående bild lade planeraren för Fabrikam-migreringen till organisationsnamnet fabrikam-import och valde CUS (Central USA) som geografisk plats för migrering. Andra värden lämnades som ska ändras precis innan planeraren tog samlingen offline för migreringen.
Kommentar
Testkörningsimporter har en "-dryrun" som läggs till automatiskt i slutet av organisationsnamnet, som du kan ändra efter migreringen.
Azure-regioner som stöds för migrering
Azure DevOps Services är tillgängligt på flera geografiska Platser i Azure. Men inte alla platser där Azure DevOps Services är tillgängligt stöds för migrering. I följande tabell visas de geografiska Platser i Azure som du kan välja för migrering. Det ingår också det värde som du behöver placera i migreringsspecifikationsfilen för att rikta in dig på det geografiska området för migrering.
| Geografisk plats | Geografisk plats i Azure | Importspecifikationsvärde |
|---|---|---|
| USA | Central USA | CUS |
| Europa | Västeuropa | VEU |
| Storbritannien | Södra Storbritannien | Storbritannien |
| Australien | Östra Australien | EAU |
| Sydamerika | Brasilien, södra | SBR |
| Asien och stillahavsområdet | Södra Indien | MA |
| Asien och stillahavsområdet | Sydostasien (Singapore) | SEA |
| Kanada | Kanada, centrala | CC |
Identitetsmappningsloggen
Identitetsmappningsloggen är lika viktig som de faktiska data som du migrerar till Azure DevOps Services. När du granskar filen är det viktigt att förstå hur identitetsmigreringen fungerar och vad de potentiella resultaten kan medföra. När du migrerar en identitet kan den bli aktiv eller historisk. Aktiva identiteter kan logga in på Azure DevOps Services, men historiska identiteter kan inte göra det.
Aktiva identiteter
Aktiva identiteter refererar till användaridentiteter i Azure DevOps Services efter migreringen. I Azure DevOps Services licensieras dessa identiteter och visas som användare i organisationen. Identiteterna markeras som aktiva i kolumnen Förväntad importstatus i identitetsmappningsloggfilen.
Historiska identiteter
Historiska identiteter mappas som sådana i kolumnen Förväntad importstatus i identitetsmappningsloggfilen. Identiteter utan radpost i filen blir också historiska. Ett exempel på en identitet utan en radpost kan vara en anställd som inte längre arbetar på ett företag.
Till skillnad från aktiva identiteter, historiska identiteter:
- Har inte åtkomst till en organisation efter migreringen.
- Har inte licenser.
- Visa inte som användare i organisationen. Allt som kvarstår är begreppet identitetens namn i organisationen, så att dess historik kan sökas senare. Vi rekommenderar att du använder historiska identiteter för användare som inte längre arbetar på företaget eller som inte behöver ytterligare åtkomst till organisationen.
Kommentar
När en identitet har importerats som historisk kan den inte bli aktiv.
Förstå identitetsmappningsloggfilen
Loggfilen för identitetskartan liknar exemplet som visas här:
Kolumnerna i identitetsmappningsloggfilen beskrivs i följande tabell:
Du och din Microsoft Entra-administratör måste undersöka användare som har markerats som Ingen matchning hittades (Kontrollera Microsoft Entra ID Sync) för att förstå varför de inte ingår i din Microsoft Entra Connect Sync.
| Kolumn | beskrivning |
|---|---|
| Active Directory: Användare (Azure DevOps Server) | Det egna visningsnamnet som används av identiteten i Azure DevOps Server. Det här namnet gör det enklare att identifiera vilken användare raden på kartan refererar till. |
| Active Directory: Säkerhetsidentifierare | Den unika identifieraren för den lokal Active Directory identiteten i Azure DevOps Server. Den här kolumnen används för att identifiera användare i samlingen. |
| Microsoft Entra-ID: Förväntad importanvändare (Azure DevOps Services) | Antingen den förväntade inloggningsadressen för den matchade snart aktiva användaren eller Ingen matchning hittades (Kontrollera Microsoft Entra ID Sync), vilket anger att identiteten gick förlorad under Microsoft Entra ID Sync och importeras som historisk. |
| Förväntad importstatus | Förväntad användarmigreringsstatus: Antingen Aktiv om det finns en matchning mellan ditt Active Directory- och Microsoft Entra-ID eller Historisk om det inte finns någon matchning. |
| Valideringsdatum | Senast identitetsmappningsloggen verifierades. |
När du läser igenom filen ser du om värdet i kolumnen Förväntad importstatus är Aktiv eller Historisk. Aktiv anger att identiteten på den här raden mappar korrekt vid migreringen blir aktiv. Historiska innebär att identiteterna blir historiska vid migrering. Det är viktigt att granska den genererade mappningsfilen för fullständighet och korrekthet.
Viktigt!
Migreringen misslyckas om större ändringar sker i synkroniseringen av säkerhets-ID för Microsoft Entra Connect mellan migreringsförsök. Du kan lägga till nya användare mellan testkörningar och du kan göra korrigeringar för att säkerställa att tidigare importerade historiska identiteter blir aktiva. Men du kan inte ändra en befintlig användare som tidigare importerades som aktiv. Det gör att migreringen misslyckas. Ett exempel på en ändring kan vara att slutföra en testkörningsmigrering, ta bort en identitet från ditt Microsoft Entra-ID som har importerats aktivt, återskapa en ny användare i Microsoft Entra-ID för samma identitet och sedan försöka utföra en ny migrering. I det här fallet försöker en aktiv identitetsmigrering mellan Active Directory och den nyligen skapade Microsoft Entra-identiteten, men orsakar ett migreringsfel.
Granska korrekt matchade identiteter. Finns alla förväntade identiteter? Är användarna mappade till rätt Microsoft Entra-identitet?
Om några värden måste ändras kontaktar du Microsoft Entra-administratören för att kontrollera att den lokal Active Directory identiteten ingår i synkroniseringen till Microsoft Entra-ID:t och konfigureras korrekt. Mer information finns i Integrera dina lokala identiteter med Microsoft Entra-ID.
Granska sedan de identiteter som är märkta som historiska. Den här etiketteringen innebär att det inte gick att hitta en matchande Microsoft Entra-identitet av någon av följande skäl:
- Identiteten är inte konfigurerad för synkronisering mellan lokal Active Directory och Microsoft Entra-ID.
- Identiteten är inte ifylld i ditt Microsoft Entra-ID ännu (till exempel finns det en ny anställd).
- Identiteten finns inte i din Microsoft Entra-instans.
- Användaren som äger den identiteten arbetar inte längre på företaget.
För att åtgärda de tre första orsakerna konfigurerar du den avsedda lokal Active Directory identiteten för synkronisering med Microsoft Entra-ID. Mer information finns i Integrera dina lokala identiteter med Microsoft Entra-ID. Du måste konfigurera och köra Microsoft Entra Connect för att identiteter ska importeras som aktiva i Azure DevOps Services.
Du kan ignorera den fjärde orsaken eftersom anställda som inte längre är på företaget ska importeras som historiska.
Historiska identiteter (små team)
Kommentar
Den strategi för identitetsmigrering som föreslås i det här avsnittet bör endast övervägas av små team.
Om Microsoft Entra Connect inte har konfigurerats markeras alla användare i identitetsmappningsloggfilen som historiska. Om du kör en migrering på det här sättet blir alla användare importerade som historiska. Vi rekommenderar starkt att du konfigurerar Microsoft Entra Connect för att säkerställa att dina användare importeras som aktiva.
Att köra en migrering med alla historiska identiteter har konsekvenser som måste beaktas noggrant. Endast team med ett fåtal användare och för vilka kostnaden för att konfigurera Microsoft Entra Connect anses vara för hög bör övervägas.
Om du vill migrera alla identiteter som historiska följer du stegen som beskrivs i senare avsnitt. När du köar en migrering startas den identitet som används för att köa migreringen till organisationen som organisationsägare. Alla andra användare importeras som historiska. Organisationsägare kan sedan lägga till användarna igen med hjälp av sin Microsoft Entra-identitet. De tillagda användarna behandlas som nya användare. De äger inte någon av sina historiker, och det finns inget sätt att återansluta den här historiken till Microsoft Entra-identiteten. Användarna kan dock fortfarande söka efter sin förmigrationshistorik genom att söka efter sin \<domain>\<Active Directory username>.
Datamigreringsverktyget visar en varning om det identifierar det fullständiga scenariot med historiska identiteter. Om du bestämmer dig för att gå den här migreringsvägen måste du godkänna begränsningarna i verktyget.
Visual Studio-prenumerationer
Datamigreringsverktyget kan inte identifiera Visual Studio-prenumerationer (kallades tidigare MSDN-förmåner) när det genererar identitetsmappningsloggfilen. I stället rekommenderar vi att du använder funktionen för automatisk licensuppgradering efter migreringen. Så länge användarnas arbetskonton är korrekt länkade tillämpar Azure DevOps Services automatiskt sina Visual Studio-prenumerationsförmåner vid den första inloggningen efter migreringen. Du debiteras aldrig för licenser som tilldelas under migreringen, så du kan hantera prenumerationer på ett säkert sätt efteråt.
Du behöver inte upprepa en testkörningsmigrering om användarnas Visual Studio-prenumerationer inte uppgraderas automatiskt i Azure DevOps Services. Visual Studio-prenumerationslänkning sker utanför migreringens omfång. Så länge deras arbetskonto är korrekt länkat före eller efter migreringen uppgraderas användarnas licenser automatiskt vid nästa inloggning. När deras licenser har uppgraderats uppgraderas användarna automatiskt vid sin första inloggning till organisationen nästa gång du kör en migrering.
Förbereda för migrering
Nu har du allt som är redo att köras vid testkörningsmigreringen. Schemalägg stilleståndstid med ditt team för att ta samlingen offline för migreringen. När du godkänner en tid för att köra migreringen laddar du upp de nödvändiga tillgångar som du genererade och en kopia av databasen till Azure. Förberedelse för migrering består av följande fem steg.
Steg 1: Ta samlingen offline och koppla från den.
Steg 2: Generera en DACPAC-fil från samlingen som du ska migrera.
Steg 3: Ladda upp DACPAC-filen och migreringsfilerna till ett Azure Storage-konto.
Steg 4: Generera en SAS-token för åtkomst till lagringskontot.
Steg 5: Slutför migreringsspecifikationen.
Kommentar
Innan du utför en produktionsmigrering rekommenderar vi starkt att du slutför en testkörningsmigrering. Med en testkörning kan du verifiera att migreringsprocessen fungerar för din samling och att det inte finns några unika dataformer som kan orsaka ett produktionsmigreringsfel.
Steg 1: Koppla från samlingen
Att koppla bort samlingen är ett viktigt steg i migreringsprocessen. Identitetsdata för samlingen finns i Konfigurationsdatabasen för Azure DevOps Server-instansen medan samlingen är ansluten och online. När en samling kopplas från Azure DevOps Server-instansen tar den en kopia av dessa identitetsdata och paketeras med samlingen för transport. Utan dessa data kan identitetsdelen av migreringen inte köras.
Dricks
Vi rekommenderar att du håller samlingen frånkopplad tills migreringen har slutförts, eftersom det inte finns något sätt att migrera de ändringar som inträffade under migreringen. Anslut samlingen igen när du har säkerhetskopierat den för migrering, så du är inte orolig för att ha de senaste data för den här typen av migrering. Om du vill undvika offlinetid helt och hållet kan du även välja att använda en offlineavkoppling för testkörningar.
Det är viktigt att väga kostnaden för att välja att medföra noll stilleståndstid för en testkörning. Det kräver att du säkerhetskopierar samlingen och konfigurationsdatabasen, återställer dem på en SQL-instans och sedan skapar en frånkopplad säkerhetskopia. En kostnadsanalys kan visa att det i slutändan är bättre att ta några timmars stilleståndstid för att direkt ta den frånkopplade säkerhetskopieringen.
Steg 2: Generera en DACPAC-fil
DACPACs erbjuder en snabb och relativt enkel metod för att flytta samlingar till Azure DevOps Services. Men när en samlingsdatabasstorlek överskrider ett visst tröskelvärde börjar fördelarna med att använda en DACPAC minska.
Kommentar
Om datamigreringsverktyget visar en varning om att du inte kan använda DACPAC-metoden måste du utföra migreringen med hjälp av metoden sql azure virtual machine (VM). Hoppa över steg 2 till 5 i det fallet och följ anvisningarna i avsnittet Förbered testkörning, Migrera stora samlingar och fortsätt sedan att fastställa migreringstypen. Om datamigreringsverktyget inte visar en varning använder du den DACPAC-metod som beskrivs i det här steget.
DACPAC är en funktion i SQL Server som gör att databaser kan paketeras i en enda fil och distribueras till andra instanser av SQL Server. En DACPAC-fil kan också återställas direkt till Azure DevOps Services, så du kan använda den som paketeringsmetod för att hämta din samlings data i molnet.
Viktigt!
- När du använder SqlPackage.exe måste du använda .NET Framework-versionen av SqlPackage.exe för att förbereda DACPAC. MSI Installer måste användas för att installera .NET Framework-versionen av SqlPackage.exe. Använd inte dotnet CLI- eller .zip-versionerna (Windows .NET 6) av SqlPackage.exe eftersom dessa versioner kan generera DACPACs som inte är kompatibla med Azure DevOps Services.
- Version 161 av SqlPackage krypterar databasanslutningar som standard och kanske inte ansluter. Om du får ett inloggningsprocessfel lägger du till
;Encrypt=False;TrustServerCertificate=Truei anslutningssträng för SqlPackage-instruktionen.
Ladda ned och installera SqlPackage.exe med hjälp av den senaste MSI Installer från Viktig information om SqlPackage.
När du har använt MSI Installer SqlPackage.exe installationer i en sökväg som liknar %PROGRAMFILES%\Microsoft SQL Server\160\DAC\bin\.
När du genererar en DACPAC bör du tänka på två saker: disken som DACPAC sparas på och diskutrymmet på datorn som genererar DACPAC. Du vill se till att du har tillräckligt med diskutrymme för att slutföra åtgärden.
När paketet skapas lagrar SqlPackage.exe tillfälligt data från din samling i temp-katalogen på enhet C på den dator som du initierar paketeringsbegäran från.
Du kanske upptäcker att enheten C är för liten för att kunna skapa en DACPAC. Du kan uppskatta hur mycket utrymme du behöver genom att leta efter den största tabellen i samlingsdatabasen. DACPACs skapas en tabell i taget. Det maximala utrymmeskravet för att köra genereringen motsvarar ungefär storleken på den största tabellen i samlingens databas. Om du sparar den genererade DACPAC för att köra C bör du överväga storleken på samlingsdatabasen som rapporterats i DataMigrationTool.log-filen från en valideringskörning.
Filen DataMigrationTool.log innehåller en lista över de största tabellerna i samlingen varje gång kommandot körs. Ett exempel på tabellstorlekar för en samling finns i följande utdata. Jämför storleken på den största tabellen med det lediga utrymmet på den enhet som är värd för din temporära katalog.
Viktigt!
Innan du fortsätter med att generera en DACPAC-fil kontrollerar du att samlingen är frånkopplad.
[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
Se till att den enhet som är värd för din temporära katalog har minst lika mycket ledigt utrymme. Om den inte gör det måste du omdirigera temp-katalogen genom att ange en miljövariabel.
SET TEMP={location on disk}
Ett annat övervägande är var DACPAC-data sparas. Om du pekar den sparade platsen på en fjärransluten fjärrenhet kan det leda till längre generationstider. Om en snabb enhet, till exempel en SSD(Solid State Drive) är tillgänglig lokalt, rekommenderar vi att du riktar in dig på enheten som plats för DACPAC-sparande. Annars är det alltid snabbare att använda en disk som finns på den dator där samlingsdatabasen finns i stället för en fjärrenhet.
Nu när du har identifierat målplatsen för DACPAC och sett till att du har tillräckligt med utrymme är det dags att generera DACPAC-filen.
Öppna ett kommandotolkfönster och gå till platsen SqlPackage.exe. Om du vill generera DACPAC ersätter du platshållarvärdena med de värden som krävs och kör sedan följande kommando:
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
- Datakälla: SQL Server-instansen som är värd för din Azure DevOps Server-samlingsdatabas.
- Ursprunglig katalog: Namnet på samlingsdatabasen.
- targetFile: Platsen på disken och DACPAC-filnamnet.
Ett DACPAC-generationskommando som körs på själva Azure DevOps Server-datanivån visas i följande exempel:
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
Kommandots utdata är en DACPAC-fil som genereras från samlingsdatabasen Foo med namnet Foo.dacpac.
Konfigurera din samling för migrering
När insamlingsdatabasen har återställts på den virtuella Azure-datorn konfigurerar du en SQL-inloggning så att Azure DevOps Services kan ansluta till databasen för att migrera data. Den här inloggningen tillåter endast läsåtkomst till en enda databas.
Starta genom att öppna SQL Server Management Studio på den virtuella datorn och sedan öppna ett nytt frågefönster mot databasen som ska importeras.
Ange databasens återställning till enkel:
ALTER DATABASE [<Database name>] SET RECOVERY SIMPLE;
Skapa en SQL-inloggning för databasen och tilldela inloggningen "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>'
I vårt Fabrikam-exempel skulle de två SQL-kommandona se ut som i följande exempel:
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'
Kommentar
Aktivera SQL Server- och Windows-autentiseringsläge i SQL Server Management Studio på den virtuella datorn. Om du inte aktiverar autentiseringsläge misslyckas migreringen.
Konfigurera migreringsspecifikationsfilen för att rikta in sig på den virtuella datorn
Uppdatera migreringsspecifikationsfilen så att den innehåller information om hur du ansluter till SQL Server-instansen. Öppna migreringsspecifikationsfilen och gör följande uppdateringar.
Ta bort DACPAC-parametern från källfilsobjektet.
Migreringsspecifikationen före ändringen visas i följande kod.
Migreringsspecifikationen efter ändringen visas i följande kod.
Fyll i de obligatoriska parametrarna och lägg till följande egenskapsobjekt i källobjektet i specifikationsfilen.
"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" }
När du har tillämpat ändringarna ser migreringsspecifikationen ut som i följande exempel.
Migreringsspecifikationen är nu konfigurerad för att använda en virtuell SQL Azure-dator för migrering. Fortsätt med resten av förberedelsestegen för migrering till Azure DevOps Services. När migreringen är klar måste du ta bort SQL-inloggningen eller rotera lösenordet. Microsoft behåller inte inloggningsinformationen när migreringen är klar.
Steg 3: Ladda upp DACPAC-filen
Kommentar
Om du använder SQL Azure VM-metoden behöver du bara ange anslutningssträng. Du behöver inte ladda upp några filer och du kan hoppa över det här steget.
DACPAC måste placeras i en Azure-lagringscontainer, som kan vara en befintlig container eller en som skapats specifikt för migreringsarbetet. Det är viktigt att se till att containern skapas på rätt geografiska platser.
Azure DevOps Services är tillgängligt på flera geografiska platser. När du importerar till dessa platser är det viktigt att placera dina data korrekt för att säkerställa att migreringen kan starta korrekt. Dina data måste placeras på samma geografiska plats som du importerar till. Om du placerar data någon annanstans kan migreringen inte startas. I följande tabell visas de godkända geografiska platserna för att skapa ditt lagringskonto och ladda upp dina data.
| Önskad geografisk plats för migrering | Geografisk plats för lagringskonto |
|---|---|
| Central USA | Central USA |
| Västeuropa | Västeuropa |
| Storbritannien | Södra Storbritannien |
| Australien, östra | Australien, östra |
| Brasilien, södra | Brasilien, södra |
| Indien, syd | Indien, syd |
| Kanada, centrala | Kanada, centrala |
| Asien och stillahavsområdet (Singapore) | Asien och stillahavsområdet (Singapore) |
Även om Azure DevOps Services är tillgängligt på flera geografiska platser i USA accepterar endast den centrala USA platsen nya Azure DevOps Services. Du kan inte migrera dina data till andra azure-platser i USA just nu.
Skapa en blobcontainer från Azure Portal. När du har skapat containern laddar du upp samlingens DACPAC-fil.
När migreringen är klar tar du bort blobcontainern och det tillhörande lagringskontot med verktyg som AzCopy eller något annat Azure Storage Explorer-verktyg, till exempel Azure Storage Explorer.
Kommentar
Om DACPAC-filen är större än 10 GB rekommenderar vi att du använder AzCopy. AzCopy har stöd för flertrådad uppladdning för snabbare uppladdningar.
Steg 4: Generera en SAS-token
En SAS-token (signatur för delad åtkomst) ger delegerad åtkomst till resurser i ett lagringskonto. Med token kan du ge Microsoft den lägsta behörighetsnivå som krävs för att komma åt dina data för att utföra migreringen.
Du kan generera SAS-token med hjälp av Azure Portal. Från säkerhetssynpunkt rekommenderar vi att du utför följande uppgifter:
- Välj endast Läs och Lista som behörigheter för din SAS-token. Inga andra behörigheter krävs.
- Ange en förfallotid högst sju dagar in i framtiden.
- Begränsa endast åtkomsten till Azure DevOps Services-IP-adresser.
- Behandla SAS-nyckeln som en hemlighet. Lämna inte nyckeln på en osäker plats eftersom den ger läs- och liståtkomst till data som du har lagrat i containern.
Steg 5: Slutför migreringsspecifikationen
Tidigare i processen fyllde du delvis i migreringsspecifikationsfilen, som kallas migration.json. Nu har du tillräckligt med information för att slutföra alla återstående fält förutom migreringstypen. Migreringstypen beskrivs senare i migreringsavsnittet.
I migration.json-specifikationsfilen, under Källa, fyller du i följande fält.
- Plats: Klistra in SAS-nyckeln som du genererade från skriptet och kopierade sedan i föregående steg.
- Dacpac: Kontrollera att filen, inklusive filtillägget .dacpac , har samma namn som DACPAC-filen som du laddade upp till lagringskontot.
Den slutliga migreringsspecifikationsfilen bör se ut som i följande exempel.
Fastställa migreringstypen
Importer kan placeras i kö som antingen en testkörning eller en produktionskörning. Parametern ImportType avgör migreringstypen:
- TestRun: Använd en testkörning i testsyfte. Systemet tar bort testkörningar efter 45 dagar.
- ProductionRun: Använd en produktionskörning när du vill behålla den resulterande migreringen och använda organisationen på heltid i Azure DevOps Services när migreringen är klar.
Dricks
Vi rekommenderar alltid att du slutför en testkörningsmigrering först.
Testkörningsorganisationer
Testkörningsorganisationer hjälper team att testa migreringen av sina samlingar. Innan en produktionsmigrering kan köras måste alla slutförda testkörningsorganisationer tas bort. Alla testkörningsorganisationer har en begränsad existens och tas automatiskt bort efter en viss tidsperiod. Information om när organisationen tas bort ingår i det lyckade e-postmeddelandet som du bör få när migreringen är klar. Var noga med att notera detta datum och planera därefter.
Testkörningsorganisationer har 45 dagar på sig innan de tas bort. Efter den angivna tidsperioden tas testkörningsorganisationen bort. Du kan upprepa testkörningsimporter så många gånger du behöver innan du utför en produktionsmigrering.
Ta bort testkörningar
Ta bort alla tidigare testkörningar innan du försöker göra ett nytt. När ditt team är redo att utföra en produktionsmigrering måste du ta bort testkörningsorganisationen manuellt. Innan du kan köra en andra testkörningsmigrering eller den sista produktionsmigreringen måste du ta bort alla tidigare Azure DevOps Services-organisationer som du skapade i en tidigare testkörning. Mer information finns i Ta bort organisation.
Dricks
Valfri information som hjälper en användare att bli mer framgångsrikEn testkörningsmigrering som följer den första förväntas ta längre tid med tanke på den extra tid som krävs för att rensa resurser från tidigare testkörningar.
Det kan ta upp till en timme innan ett organisationsnamn blir tillgängligt när du har raderat eller bytt namn. Mer information finns i artikeln Efter migreringsuppgifter .
Om du stöter på migreringsproblem kan du läsa Felsöka migrerings- och migreringsfel.
Köra en migrering
Ditt team är nu redo att påbörja processen med att köra en migrering. Vi rekommenderar att du börjar med en lyckad testkörningsmigrering innan du försöker utföra en produktionskörningsmigrering. Med testkörningsimporter kan du i förväg se hur en migrering ser ut, identifiera potentiella problem och få erfarenhet innan du går in i din produktionskörning.
Kommentar
- Om du behöver upprepa en slutförd produktionskörningsmigrering för en samling, som i händelse av en återställning, kontaktar du Kundsupport för Azure DevOps Services innan du köar en annan migrering.
- Azure-administratörer kan hindra användare från att skapa nya Azure DevOps-organisationer. Om Microsoft Entra-klientprincipen är aktiverad kan migreringen inte slutföras. Innan du börjar kontrollerar du att principen inte har angetts eller att det finns ett undantag för den användare som utför migreringen. Mer information finns i Begränsa organisationsskapande via Microsoft Entra-klientprincip.
- Azure DevOps Services stöder inte kvarhållningsprinciper per pipeline och de överförs inte till den värdbaserade versionen.
Överväganden för återställningsplaner
Ett vanligt problem för team som gör en slutlig produktionskörning är deras återställningsplan, om något går fel med migreringen. Vi rekommenderar starkt att du gör en testkörning för att se till att du kan testa de migreringsinställningar som du anger i datamigreringsverktyget för Azure DevOps.
Återställning för den slutliga produktionskörningen är ganska enkel. Innan du köar migreringen kopplar du bort gruppprojektsamlingen från Azure DevOps Server, vilket gör den otillgänglig för dina teammedlemmar. Om du av någon anledning behöver återställa produktionskörningen och föra den lokala servern online igen för dina teammedlemmar kan du göra det. Bifoga gruppprojektsamlingen lokalt igen och informera ditt team om att de fortsätter att arbeta normalt medan teamet omgrupperar för att förstå eventuella fel.
Du kan sedan kontakta Kundsupport för Azure DevOps Services för att få hjälp med att förstå orsaken till felet om du inte kan fastställa orsaken. Mer information finns i artikeln Felsökning. Kundsupportärenden kan öppnas från följande sida https://aka.ms/AzureDevOpsImportSupport. Det är viktigt att observera att om problemet kräver att produktgruppstekniker engagerar sig kommer dessa ärenden att hanteras under ordinarie kontorstid.
Koppla från din gruppprojektsamling från Azure DevOps Server för att förbereda den för migrering.
Innan du genererar en säkerhetskopia av SQL-databasen kräver datamigreringsverktyget att samlingen är helt frånkopplad från Azure DevOps Server (inte SQL). Frånkopplingsprocessen i Azure DevOps Server överför användaridentitetsinformation som lagras utanför samlingsdatabasen och gör den portabel att flytta till en ny server eller i det här fallet till Azure DevOps Services.
Det är enkelt att koppla från en samling från Administrationskonsolen för Azure DevOps Server på din Azure DevOps Server-instans. Mer information finns i Flytta projektsamling, Koppla från samlingen.
Köa migreringen
Viktigt!
Innan du fortsätter kontrollerar du att samlingen har kopplats från innan du genererar en DACPAC-fil eller laddar upp samlingsdatabasen till en virtuell SQL Azure-dator. Om du inte slutför det här steget misslyckas migreringen. Om migreringen misslyckas läser du Lösa migreringsfel.
Starta en migrering med hjälp av datamigreringsverktygets importkommando . Migreringskommandot tar en migreringsspecifikationsfil som indata. Den parsar filen för att säkerställa att de angivna värdena är giltiga och, om det lyckas, köar den en migrering till Azure DevOps Services. Migreringskommandot kräver en Internetanslutning, men kräver inte* en anslutning till din Azure DevOps Server-instans.
Kom igång genom att öppna kommandotolken och ändra kataloger till sökvägen till datamigreringsverktyget. Vi rekommenderar att du granskar hjälptexten som medföljer verktyget. Kör följande kommando för att se vägledningen och hjälpen för migreringskommandot:
Migrator import /help
Kommandot för att köa en migrering har följande struktur:
Migrator import /importFile:{location of migration specification file}
I följande exempel visas ett slutfört migreringskommando:
Migrator import /importFile:C:\DataMigrationToolFiles\migration.json
När valideringen har godkänts loggar du in på Microsoft Entra-ID med en identitet som är medlem i samma Microsoft Entra-klientorganisation som identitetsmappningsloggfilen skapades mot. Den inloggade användaren är ägare till den importerade organisationen.
Kommentar
Varje Microsoft Entra-klientorganisation är begränsad till fem importer per 24-timmarsperiod. Endast importer som är köade räknas mot det här taket.
När ditt team initierar en migrering skickas ett e-postmeddelande till den användare som köade migreringen. Ungefär 5 till 10 minuter efter att migreringen har placerats i kö kan ditt team gå till organisationen för att kontrollera statusen. När migreringen är klar dirigeras ditt team att logga in och ett e-postmeddelande skickas till organisationens ägare.
Datamigreringsverktyget flaggar fel som du behöver korrigera före migreringen. Den här artikeln beskriver de vanligaste varningar och fel som du kan få när du förbereder migreringen. När du har korrigerat varje fel kör du kommandot migrator validate igen för att verifiera lösningen.