Migreringsöversikt

Att flytta från Azure DevOps Server till Azure DevOps Services är ett viktigt steg för organisationer som vill dra nytta av molnbaserat samarbete, skalbarhet och förbättrade funktioner. I den här översikten utforskar vi alternativen för att överföra värdefulla data från den lokala Azure DevOps Server till molnbaserade Azure DevOps Services.

Oavsett det valda migreringsalternativet rekommenderar vi att du fastställer dina viktigaste tillgångar, till exempel källkod och arbetsobjekt. Du bör tänka på din datastorlek, organisationskomplexitet och se till att du har tillräckligt med tid för testkörningar innan den faktiska migreringen för en smidig och lyckad övergång.

Metoder för migrering

Det är viktigt att utvärdera för- och nackdelarna med varje migreringsmetod baserat på dina specifika motivationer för att införa Azure DevOps Services. Rätt strategi beror på din unika kontext och dina krav.

Alternativ 1: Manuell migrering

När Till exempel Azure DevOps-teamet på Microsoft valde att flytta från Azure DevOps Server till Azure DevOps Services bestämde vi oss också för att flytta från Team Foundation Version Control (TFVC) till Git. Migrering krävde mycket planering, men när vi migrerade skapade vi en ny Git-lagringsplats med hjälp av "tips"-versionen av våra TFVC-källor och lämnade vår historik kvar i Azure DevOps Server. Vi flyttade också våra aktiva arbetsobjekt och lämnade efter oss alla våra gamla buggar, slutförda användarberättelser och uppgifter och så vidare.

Manuell migreringsprocess

1. Identifiera de viktigaste tillgångarna som du behöver migrera – vanligtvis källkod, arbetsobjekt eller båda. Andra tillgångar i Azure DevOps Server – byggpipelines, testplaner och så vidare – är svårare att migrera manuellt.
2. Identifiera en lämplig tid för övergången.
3. Förbered dina målorganisationer. Skapa de organisationer och teamprojekt som du behöver, etablera användare och så vidare.
4. Migrera dina data.
5. Överväg att göra Azure DevOps Server-källdistributionerna skrivskyddade. Du kan göra det på följande sätt:
   • Justera behörigheter på projektnivå: Ange behörigheter för alla användare eller grupper till skrivskyddade på projektnivå, vilket du kan göra genom att ändra säkerhetsrollerna i Project-inställningarna.
   • Ändra lagringsplatsens inställningar: För varje lagringsplats kan du ändra inställningarna så att de blir skrivskyddade, vilket innebär att du justerar behörigheterna för varje användare eller grupp för att endast tillåta läsåtgärder.
   • Använd inbyggda säkerhetsgrupper: Använd de inbyggda säkerhetsgrupperna för att hantera behörigheter mer effektivt. Du kan tilldela användare till grupper som "Läsare" för att ge skrivskyddad åtkomst.
   • Skriptbehörighetsändringar: Om du har många projekt eller lagringsplatser kan du behöva skripta dem. Du kan använda Azure CLI DevOps-tillägget för att visa alla behörigheter och uppdatera dem efter behov.
   • Inaktivera lagringsplatsfunktion: Inaktiverar åtkomst till lagringsplatsen, inklusive byggen och pull-begäranden, men håller lagringsplatsen identifierad med en varning. Gå till Projektinställningar>Lagringsplatser> i ditt arkiv och bredvid Inaktivera arkiv, flytta reglaget till På.

Alternativ 2: Datamigreringsverktyget för Azure DevOps

Azure DevOps Data Migration Tool är en uppsättning verktyg som tillhandahålls av Microsoft för att underlätta migreringen av data från Azure DevOps Server till Azure DevOps Services. Dessa verktyg erbjuder en effektiv metod för att migrera olika artefakter, inklusive källkod, arbetsobjekt, testfall och andra projektrelaterade data.

Innan du påbörjar migreringsprocessen kan verktygen utföra en förmigrationsanalys för att utvärdera beredskapen för källmiljön och identifiera potentiella problem eller beroenden som kan påverka migreringen. Utvärdera beredskapen så att du kan planera och minimera potentiella utmaningar i förväg.

Begränsningar för migreringsverktyget

Med verktyget kan du "lyfta och flytta" en Azure DevOps Server-samling till en ny Azure DevOps Services-organisation, utan ändringar av följande skäl:

Varför inga ändringar tillåts

• Dataintegritet och konsekvens: Ändringar under migreringen kan leda till skadade data eller inkonsekvenser.
• Bevarande av källdata: Verktyget replikerar källdata troget utan ändringar som kan orsaka avvikelser.
• Förutsägbart beteende: Genom att begränsa ändringar säkerställs konsekventa och tillförlitliga migreringsresultat.
• Migreringsfokus, inte transformering: Verktyget flyttar data; transformering sker separat efter migreringen.

Migreringsscenarier som inte stöds

• Flytta projekt från en Azure DevOps Services-organisation till en annan Azure DevOps Services-organisation
• Migrera från en Azure DevOps Server-instans till en annan Azure DevOps Server-instans

Regionala begränsningar

Datamigreringsverktyget stöds endast i specifika Azure-regioner. Organisationer måste skapas i regioner som stöds och eventuell tillfällig infrastruktur (till exempel virtuella SQL-datorer för stora migreringar) måste också distribueras i dessa regioner. Se Regioner som stöds för migrering för den fullständiga listan.

Migreringsverktygsprocess

1. Slutför förutsättningarna, till exempel att uppdatera Azure DevOps Server till en av de två senaste versionerna.
2. Verifiera varje samling som du vill flytta till Azure DevOps Services.
3. Generera migreringsfiler.
4. Förbered allt för genomförandet av migreringen.
5. Utför en testkörning.
6. Utför en migrering.
7. Bekräfta att dina användare och data har migrerats och att samlingen fungerar som förväntat.

Alternativ 3: API-baserad migrering

Om du inte kan använda datamigreringsverktyget men ändå vill ha en migrering med högre återgivning än alternativ 2 kan du överväga att använda olika verktyg som använder offentliga API:er för att flytta data. De här verktygen innehåller tillägg som är tillgängliga på Visual Studio Marketplace.

API-baserade migreringsbegränsningar

Följande begränsningar uppstår med API-baserad migrering:

• Migrering med låg detaljeringsgrad:
  • Begränsning: API-baserade verktyg ger högre noggrannhet än manuell kopiering men har fortfarande relativt låg noggrannhet.
  • Implikation: Även om dessa verktyg erbjuder viss återgivning bevarar de inte alla aspekter av dina data.
    • Exempel: Ingen av dem behåller de ursprungliga datumen för TFVC-ändringsuppsättningar (Team Foundation Version Control).
    • Många bevarar inte heller de ändrade datumen för arbetsobjektsrevisioner.
• Dataförlust och ID-ändringar:
  • Begränsning: Under migreringen återspelar verktygen ändringar av arbetsobjekt, TFVC-ändringsuppsättningar, paketflöden och pipeline-artefakter.
  • Implikation: Den här processen kan leda till dataförlust, generera nya ID:n och ändra datum för skapande, ändring och stängning.
    • Exempel: Historisk kontext som är kopplad till specifika datum kan gå förlorad, vilket påverkar rapportering och spårbarhet.

API-baserad migreringsprocess

Generellt rekommenderar vi endast denna metod om extra noggrannhet utöver en manuell kopia är kritisk. Om du bestämmer dig för att använda den här metoden kan du överväga att anställa en konsult som har erfarenhet av ett eller flera av verktygen och utföra en testmigrering före den slutliga migreringen.

Många organisationer behöver en migrering med hög precision för endast en del av deras arbete. Nytt arbete kan potentiellt börja direkt i Azure DevOps Services. Andra arbeten, med mindre stränga återgivningskrav, kan migreras med någon av de andra metoderna.

Processmodeller som stöds

Azure DevOps Services stöder följande processmodeller:

• Ärvd
• Hostad XML

Som standard är värdbaserad XML inaktiverat i Azure DevOps Services. Vi aktiverar endast den värdbaserade XML-processmodellen under migreringen om du har anpassat ett projekt i Azure DevOps Server. När projektet finns i värdbaserad XML kan du uppgradera det till ärvt efter migreringen.

Nyckelprinciper

När du migrerar till Azure DevOps Services bör du tänka på följande viktiga principer och begränsningar:

• Azure DevOps Services är endast engelska: Azure DevOps Server stöder flera språk, men i dag stöder Azure DevOps Services endast engelska. Om din samling använder det icke-engelska språket eller använt icke-engelska tidigare och du konverterade språket till engelska under en uppgradering, kan du inte använda datamigreringsverktyget.
• Arv: Ett projekt som skapades från processmallen Agile, Scrum eller CMMI och aldrig anpassades finns i arvsprocessmodellen efter migreringen.
• Värdbaserad XML: Alla projekt med anpassningar använder den värdbaserade XML-processmodellen.
• Process per anpassat projekt: Även om Azure DevOps Services tillåter att projekt delar en process skapar datamigreringsverktyget en värdbaserad XML-process för varje anpassat teamprojekt. Om du till exempel har 30 anpassade projekt har du 30 värdbaserade XML-processer att hantera. Om du vill anpassa xml-processen för alla dina projekt ytterligare måste du uppdatera varje värdbaserad XML-process separat.
• Processvalidering: Processverifieringen av datamigreringsverktyget identifierar målprocessmodellen för varje projekt. Innan du kan migrera måste du åtgärda eventuella processvalideringsfel för värdbaserade XML-projekt. Du kanske vill överväga att uppdatera processen för dina projekt så att den matchar någon av våra processer (Agile, Scrum eller CMMI) för att dra nytta av arvsprocessmodellen. Läs mer om processvalideringstyperna i vår dokumentation.

Resurser

• Rapportera ett problem i utvecklarcommunityn
• Få support och ge feedback

Nästa steg

Relaterat innehåll

• Fullständiga krav för migrering
• Verifiera och förbereda migreringen
• Förbereda för testkörning
• Genomför testmigrering
• Migrera till Azure DevOps Services
• Slutför uppgifter efter migreringen