Validerings- och importprocesser

  • Artikel

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

Den här artikeln beskriver de förberedelser som krävs för att få en import till Azure DevOps Services redo att köras. Om du får fel under processen kan du läsa Felsöka import- och migreringsfel.

Förutsättningar

  • Du måste konfigurera en Microsoft Entra-klientorganisation enligt beskrivningen i Microsoft Entra Anslut Sync: Ändra standardkonfigurationen. Datamigreringsverktyget konfigurerar en länk till din Microsoft Entra-klientorganisation när din Azure DevOps Services-organisation skapas som en del av början av importprocessen. När du synkroniserar din lokal Active Directory med Microsoft Entra-ID kan dina teammedlemmar använda samma autentiseringsuppgifter för att autentisera och dina Azure DevOps Services-administratörer kan använda dina Active Directory-grupper för att ange behörigheter i din Azure DevOps Services-organisation. Om du vill konfigurera synkroniseringen använder du Microsoft Entra-Anslut teknik.
  • Innan du påbörjar importuppgifterna kontrollerar du att du kör en version av Azure DevOps Server som stöds.
  • Vi rekommenderar att du använder migreringsguiden steg för steg för att gå vidare med din import. Guiden länkar till teknisk dokumentation, verktyg och metodtips.

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.

  1. Ladda ned verktyget

  2. Kopiera zip-filen till en av dina Azure DevOps Server-programnivåer

  3. 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.

  4. Ö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 /help

    b. Visa hjälptexten för kommandot:

     Migrator validate /help

  5. Som första gången du verifierar en samling ska vi hålla den enkel. Kommandot bör ha följande 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 , skulle kommandot vilja ha exemplet:

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

  6. 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 skulle kommandot se 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.

  7. När valideringen är klar kan du visa loggfilerna och resultaten.

    Skärmbild av valideringsresultaten och loggarna i kommandotolkens fönster.

    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 importprocessen. Om datamigreringsverktyget flaggar några fel korrigerar du dem innan du fortsätter. Vägledning om hur du korrigerar verifieringsfel finns i Felsöka import- 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 importera 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.

Generera importfiler

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 importfilerna. När du kör prepare kommandot genererar du två importfiler:

  • IdentityMapLog.csv: Beskriver din identitetskarta mellan Active Directory och Microsoft Entra ID.
  • import.json: Kräver att du fyller i importspecifikationen som du vill använda för att starta migreringen.

Kommandot Förbered

Kommandot prepare hjälper till med att generera nödvändiga importfiler. 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 verktyget Microsoft Entra Anslut (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. Importspecifikationsfilen, import.json, bör fyllas i före importen.

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 importfiler.

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 testimport 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 identitetsimport 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 visas en uppsättning loggar och två importfiler i resultatfönstret. Leta reda på en loggmapp och två filer i loggkatalogen:

  • import.json är importspecifikationsfilen. 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 import.

De två filerna beskrivs mer detaljerat i nästa avsnitt.

Importspecifikationsfilen

Importspecifikationen, import.json, är en JSON-fil som innehåller importinstä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 importera.

Skärmbild av en nyligen genererad importspecifikationsfil.

Den import.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 import. 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 importdata. Ingen åtgärd krävs. Granska informationen för de underfältsåtgärder som ska följas.
DACPAC En DACPAC-fil som paketera samlingsdatabasen som ska användas för att hämta data under importen. 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 importera 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 importen. Ange ett namn. Namnet kan snabbt ändras senare efter att importen har slutförts.
Obs! Skapa inte en organisation med det här namnet innan du kör importen. Organisationen skapas som en del av importprocessen.
ImportType Den typ av import som du vill köra. Ingen åtgärd krävs. I ett senare steg väljer du vilken typ av import som ska köras.
Valideringsdata Information som behövs för att driva din importupplevelse. Datamigreringsverktyget genererar avsnittet "ValidationData". Den innehåller information som hjälper dig att driva din importupplevelse. Redigera inte värdena i det här avsnittet eller så kan importen inte 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.

Skärmbild av en delvis slutförd importspecifikationsfil.

I föregående bild lade planeraren för Fabrikam-importen till organisationsnamnet fabrikam-import och valde CUS (Central USA) som geografisk plats för import. Andra värden lämnades som ska ändras precis innan planeraren tog samlingen offline för migreringen.

Kommentar

Torrkörningsimporter har en "-dryrun" som läggs till automatiskt i slutet av organisationsnamnet, som du kan ändra efter importen.

Azure geografiska platser som stöds för import

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 import. I följande tabell visas de geografiska Platser i Azure som du kan välja för import. Det ingår också det värde som du behöver placera i importspecifikationsfilen för att rikta in dig på det geografiska området för import.

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 identitetsimport fungerar och vad de potentiella resultaten kan medföra. När du importerar 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 importen. 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:

Skärmbild av en loggfil för identitetskarta som genereras av datamigreringsverktyget.

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-Anslut 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 inte hittas under Microsoft Entra ID Sync och importeras som historisk.
Förväntad importstatus Förväntad användarimportstatus: 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 mappas korrekt vid importen blir aktiv. Historiska innebär att identiteterna blir historiska vid import. Det är viktigt att granska den genererade mappningsfilen för fullständighet och korrekthet.

Viktigt!

Importen misslyckas om större ändringar görs i microsoft Entra-Anslut synkronisering av säkerhets-ID mellan importförsök. Du kan lägga till nya användare mellan torra körningar och du kan göra korrigeringar för att säkerställa att tidigare importerade historiska identiteter blir aktiva. Det går dock inte att ändra en befintlig användare som tidigare importerades som aktiv just nu. Om du gör det misslyckas importen. Ett exempel på en ändring kan vara att slutföra en torrkörningsimport, 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 importera igen. I det här fallet försöker en aktiv identitetsimport mellan Active Directory och den nyligen skapade Microsoft Entra-identiteten, men orsakar ett importfel.

  1. 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 är en del av synkroniseringen till Microsoft Entra-ID:t och har konfigurerats korrekt. Mer information finns i Integrera dina lokala identiteter med Microsoft Entra-ID.

  2. 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 Anslut 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 identitetsimport som föreslås i det här avsnittet bör endast beaktas av små team.

Om Microsoft Entra Anslut inte har konfigurerats markeras alla användare i identitetsmappningsloggfilen som historiska. Om du kör en import på det här sättet blir alla användare importerade som historiska. Vi rekommenderar starkt att du konfigurerar Microsoft Entra Anslut för att säkerställa att dina användare importeras som aktiva.

Att köra en import 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 Anslut anses vara för hög bör övervägas.

Om du vill importera alla identiteter som historiska följer du stegen som beskrivs i senare avsnitt. När du köar en import startas den identitet som används för att köa importen 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ändare kan dock fortfarande leta upp sin förimporthistorik genom att söka efter sitt <active directory-domänanvändarnamn><>.

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 identitetskartans loggfil. I stället rekommenderar vi att du använder funktionen för automatisk licensuppgradering efter importen. 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 importen. Du debiteras aldrig för licenser som har tilldelats under importen, så du kan hantera prenumerationer på ett säkert sätt efteråt.

Du behöver inte upprepa en torrkörningsimport om användarnas Visual Studio-prenumerationer inte uppgraderas automatiskt i Azure DevOps Services. Visual Studio-prenumerationslänkning sker utanför omfånget för en import. Så länge deras arbetskonto är korrekt länkat före eller efter importen 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 import.

Förbered för import

Nu har du allt som är redo att köras vid importen. Schemalägg stilleståndstid med ditt team för att ta samlingen offline för migreringen. När du samtycker till en tid för att köra importen laddar du upp de nödvändiga tillgångar som du genererade och en kopia av databasen till Azure. Förberedelse för import består av följande fem steg.

Steg 1: Ta samlingen offline och koppla från den.

Samlingens storleksgräns för DACPAC-metoden är 150 GB. Om datamigreringsverktyget visar en varning om att du inte kan använda DACPAC-metoden måste du utföra importen med hjälp av metoden sql azure virtual machine (VM). Hoppa över steg 2 till 5 i det fallet och följ anvisningarna i Importera stora samlingar och fortsätt sedan att ta reda på importtypen.

Steg 2: Generera en DACPAC-fil från samlingen som du ska importera.
Steg 3: Ladda upp DACPAC-filen och importera filer till ett Azure-lagringskonto.
Steg 4: Generera en SAS-token för åtkomst till lagringskontot.
Steg 5: Slutför importspecifikationen.

Kommentar

Innan du utför en produktionsimport rekommenderar vi starkt att du slutför en torrkörningsimport. Med en torr körning kan du verifiera att importprocessen fungerar för din samling och att det inte finns några unika dataformer som kan orsaka ett produktionsimportfel.

Steg 1: Koppla från samlingen

Att koppla bort samlingen är ett viktigt steg i importprocessen. 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 inte identitetsdelen av importen köras. Vi rekommenderar att du håller samlingen frånkopplad tills importen har slutförts, eftersom det inte finns något sätt att importera ändringarna som inträffade under importen.

För en torr körningsimport (test) rekommenderar vi att du kopplar om samlingen när du har säkerhetskopierat den för import, så du är inte orolig för att ha de senaste data för den här typen av import. Om du vill undvika offlinetid helt och hållet kan du också välja att använda en offlineavkoppling för torra körningar.

Det är viktigt att väga kostnaden för att välja att medföra noll stilleståndstid för en torr kö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 importen med hjälp av metoden SQL Azure virtual machine (VM) som anges i Importera stora samlingar.

Om datamigreringsverktyget inte visar någon 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=True i 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 spara-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 import

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 importera 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 [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'

Kommentar

Se till att aktivera SQL Server- och Windows-autentiseringsläge i SQL Server Management Studio på den virtuella datorn. Om du inte aktiverar autentiseringsläge misslyckas importen.

Konfigurera importspecifikationsfilen för att rikta in sig på den virtuella datorn

Uppdatera importspecifikationsfilen så att den innehåller information om hur du ansluter till SQL Server-instansen. Öppna importspecifikationsfilen och gör följande uppdateringar.

  1. Ta bort DACPAC-parametern från källfilsobjektet.

    Importspecifikationen före ändringen visas i följande kod.

    Skärmbild av importspecifikationen före ändringen.

    Importspecifikationen efter ändringen visas i följande kod.

    Skärmbild av importspecifikationen efter ändringen.

  2. 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 importspecifikationen ut som i följande exempel.

Skärmbild av importspecifikationen som refererar till en virtuell SQL Azure-dator.

Din importspecifikation har nu konfigurerats för att använda en virtuell SQL Azure-dator för import. Fortsätt med resten av förberedelsestegen för att importera till Azure DevOps Services. När importen är klar måste du ta bort SQL-inloggningen eller rotera lösenordet. Microsoft behåller inte inloggningsinformationen när importen har slutförts.

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 importen kan starta. Dina data måste placeras på samma geografiska plats som du importerar till. Om du placerar data någon annanstans kan importen 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 importplats 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 för närvarande inte importera dina data till andra azure-platser i USA.

Du kan skapa en blobcontainer från Azure-portalen. När du har skapat containern laddar du upp samlingens DACPAC-fil.

När importen är klar tar du bort blobcontainern och det tillhörande lagringskontot med användningsverktyg 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 köra importen.

SAS-token kan genereras med hjälp av Azure-portalen. Ur säkerhetssynpunkt rekommenderar vi följande:

  1. Välj endast Läs och Lista som behörigheter för din SAS-token. Inga andra behörigheter krävs.
  2. Ange en förfallotid högst sju dagar in i framtiden.
  3. Begränsa endast åtkomsten till Azure DevOps Services-IP-adresser.
  4. Placera SAS-token på en säker plats.

Steg 5: Slutför importspecifikationen

Tidigare i processen fyllde du delvis i importspecifikationsfilen, som kallas import.json. Nu har du tillräckligt med information för att slutföra alla återstående fält förutom importtypen. Importtypen beskrivs senare i importavsnittet.

I import.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 importspecifikationsfilen bör se ut som i följande exempel.

Skärmbild av den slutförda importspecifikationsfilen.

Begränsa endast åtkomsten till Azure DevOps Services-IP-adresser

Mer information finns i Begränsa åtkomst till Ip-adresser för Azure DevOps Services.

Alternativ 1: Använda tjänsttaggar

Du kan enkelt tillåta anslutningar från alla geografiska platser i Azure DevOps Services genom att lägga till azuredevopstjänsttaggen i dina nätverkssäkerhetsgrupper eller brandväggar antingen via portalen eller programmatiskt.

Alternativ 2: Använda IpList

IpList Använd kommandot för att hämta listan över IP-adresser som måste beviljas åtkomst för att tillåta anslutningar från en specifik geografisk plats i Azure DevOps Services.

I hjälpdokumentationen finns instruktioner och exempel för att köra Migrator 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 IpList /collection:{CollectionURI} /tenantDomainName:{name} /region:{region}

Du kan lägga till listan över IP-adresser i dina nätverkssäkerhetsgrupper eller brandväggar antingen via portalen eller programatiskt.

Fastställa importtypen

Importer kan placeras i kö som antingen en torrkörning eller en produktionskörning. Parametern ImportType avgör importtypen:

  • DryRun: Använd en torrkörning i testsyfte. Systemet tar bort torra körningar efter 21 dagar.
  • ProductionRun: Använd en produktionskörning när du vill behålla den resulterande importen och använda organisationen på heltid i Azure DevOps Services när importen har slutförts.

Dricks

Vi rekommenderar alltid att du slutför en torrkörningsimport först.

Slutförd importspecifikationsfil med importtyp

Torrkörda organisationer

Torrkörningsimport hjälper teamen att testa migreringen av sina samlingar. Organisationer förväntas inte finnas kvar för alltid utan finnas under en kort tid. Innan en produktionsmigrering kan köras måste alla slutförda torrkörningsorganisationer tas bort. Alla organisationer med torrkörning 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 importen har slutförts. Var noga med att notera detta datum och planera därefter.

De flesta organisationer med torrkörning har 15 dagar på sig innan de tas bort. Organisationer med torrkörning kan också ha en 21-dagars giltighetstid om fler än 100 användare har en grundläggande eller större licens vid importtillfället. Efter den angivna tidsperioden tas den torra organisationen bort. Du kan upprepa torrkörningsimporter så många gånger du behöver innan du utför en produktionsmigrering. Du måste ta bort tidigare torra körningar innan du försöker med en ny. När ditt team är redo att utföra en produktionsmigrering måste du ta bort den torra organisationen manuellt.

Mer information om aktiviteter efter importen finns i artikeln efter import .

Om du stöter på importproblem kan du läsa Felsöka import- och migreringsfel.

Kör en import

Ditt team är nu redo att börja köra en import. Vi rekommenderar att du börjar med en lyckad torrkörningsimport innan du försöker importera produktion. Med torrkörningsimport kan du i förväg se hur en import ser ut, identifiera potentiella problem och få erfarenhet innan du går in i produktionskörningen.

Kommentar

  • Om du behöver upprepa en slutförd produktionskörningsimport 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 import.
  • Azure-administratörer kan hindra användare från att skapa nya Azure DevOps-organisationer. Om Microsoft Entra-klientprincipen är aktiverad kan importen 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 importen. Vi rekommenderar starkt att du gör en torrkörning för att se till att du kan testa importinställningarna som du anger för datamigreringsverktyget för Azure DevOps.

Återställning för den slutliga produktionskörningen är ganska enkel. Innan du köar importen kopplar du från 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.

Köa en import

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 importen. Om importen misslyckas läser du Felsöka import- och migreringsfel.

Starta en import med hjälp av datamigreringsverktygets importkommando . Importkommandot tar en importspecifikationsfil 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 import till Azure DevOps Services. Importkommandot kräver en Internetanslutning, men kräver inte* en anslutning till din Azure DevOps Server-instans.

Kom igång genom att öppna ett kommandotolkfönster 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 importkommandot:

Migrator import /help

Kommandot för att köa en import har följande struktur:

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

I följande exempel visas ett slutfört importkommando:

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

När valideringen har godkänts uppmanas du att logga in på Microsoft Entra-ID. Det är viktigt att logga in 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 import skickas ett e-postmeddelande till användaren som köade importen. Ungefär 5 till 10 minuter efter att importen har placerats i kö kan ditt team gå till organisationen för att kontrollera statusen. När importen är klar dirigeras ditt team att logga in och ett e-postmeddelande skickas till organisationens ägare.