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.

Information om de största skillnaderna mellan lokal Azure DevOps Server och molnbaserade Azure DevOps Services finns i Jämför Azure DevOps Services med Azure DevOps Server – Azure DevOps.

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> på lagringsplatsen och flytta reglaget till På bredvid Inaktivera lagringsplats.

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-tjänstorganisation, utan ändringar av följande skäl:

• Dataintegritet och konsekvens:
  • När du migrerar data är det viktigt att upprätthålla integritet och konsekvens. Att tillåta ändringar under migreringen kan leda till skadade data eller inkonsekvenser.
  • Verktyget säkerställer att data förblir intakta under överföringsprocessen, vilket minimerar risken för fel.
• Bevarande av källdata:
  • Migreringsverktyget syftar till att troget replikera källdata i målmiljön.
  • Ändringar kan ändra ursprungliga data, vilket kan orsaka avvikelser mellan migrerade data och källdata.
• Förutsägbart beteende:
  • Genom att begränsa ändringar säkerställer verktyget förutsägbart beteende under migreringen.
  • Användare kan förlita sig på konsekventa resultat utan oväntade ändringar.
• Migreringsfokus, inte transformering:
  • Det primära syftet med migreringsverktyget är att flytta data från en plats till en annan.
  • Datatransformering (till exempel ändra värden) hanteras vanligtvis separat efter migreringen.

Du kan rensa data som du inte behöver före eller efter migreringen.

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 migreringskörningen.
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 av någon anledning inte kan använda datamigreringsverktyget men ändå vill ha en migrering med högre återgivning än alternativ 2 kan du välja mellan olika verktyg som använder offentliga API:er för att flytta data.

API-baserade migreringsbegränsningar

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

• Migrering med låg återgivning:
  • Begränsning: API-baserade verktyg ger högre återgivning än manuell kopiering men är fortfarande relativt låg återgivning.
  • 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 spelar verktygen upp ändringar av arbetsobjekt, TFVC-ändringsuppsättningar, paketflöden och pipelineartefakter.
  • 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

I allmänhet rekommenderar vi bara den här metoden om extra återgivning 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 mycket hög återgivningsmigrering för endast en delmängd av sitt 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
• Värdbaserad 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

Relaterade artiklar

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