Migrering från Jira till VSTS: migrera arbetsobjekt

Planeringsverktygen Jira och VSTS liknar varandra på många sätt, eftersom de båda är utformade för att lösa samma typer av problem. Men som väntat har de olika angreppssätt för dessa problem. Det gäller bland annat terminologi och implementation. Därför är det inte så enkelt som man skulle önska att migrera befintliga data.

I det här blogginlägget tittar vi på hur du kan gå tillväga vid en migrering från Jira till VSTS (Visual Studio Team Services). Vi går också igenom vilka förväntningar och möjligheter som finns kring vilka data vi vill bevara, samt några viktiga anpassningar att göra under övergången.

Vad behöver vi migrera?

Låt oss titta på vad vi vill migrera vid övergången från Jira till VSTS:

• Egenskaper för ärenden

• Länkar mellan ärenden

• Bilagor

• Kopplingar till externa artefakter (builds, commits)

• Strukturell information (backlog/sprint): när börjar och slutar sprintarna? Vilka sprintar har vilka objekt tilldelade? Prioritet i backloggen?

• Historisk information: vem skapade vilket ärende och när? Vem stängde det och när? När öppnades det igen? Lades en länk till samtidigt?

Anpassningar av workflow och namngivning

Båda verktygen har omfattande stöd för anpassning, från mindre ändringar i färdiga processmallar till att definiera helt unika processer. Oavsett om du använder Jira som det är eller har anpassat workflowet mycket, är första steget att se över era nuvarande arbetssätt och hur de motsvarar det ni vill uppnå i VSTS. Som exempel kan vi titta på några av skillnaderna mellan Scrum-processmallarna i Jira och VSTS.

När du omvandlar ett Jira-ärende till ett VSTS work item behöver du först avgöra vilken typ det nya work item ska ha.

Skillnader i typ och hierarki

Låt oss jämföra de olika typerna:

Fig. 1. Hierarki för ärendetyper i Jira

I bilderna ovan ser vi att skillnaden inte bara handlar om namngivning (till exempel att Jira-deluppgifter motsvarar VSTS-uppgifter), utan även om semantik kopplad till processmallarnas workflow och stöd i användargränssnittet. Det saknas en Jira-motsvarighet till VSTS features, och både stories och tasks i Jira kan betraktas som ett VSTS product backlog item.

Några frågor att ha i åtanke:

Planerar ditt team att använda funktioner för portföljhantering i VSTS? Hur många backloggnivåer behöver ni? Behöver ni skilja mellan Jira Story och Task?

Skillnader i status

Implementationerna skiljer sig ytterligare när det gäller statusar:

Statusarna för VSTS tasks är tillräckligt lika Jira-statusarna, men hur är det med PBI-statusar? To Do kan motsvara både New och Approved, och In Progress kan motsvara både Approved och Committed. Den semantiska skillnaden kanske inte går att lösa enbart genom att mappa statusnamn. Du behöver också granska sprintarna för stories, tasks och sub-tasks som är In Progress.

Dessutom behöver du veta om Jira-mallen har anpassats med ytterligare statusar. Om så är fallet, vad används de till? Finns det en motsvarighet i VSTS? Svaret på den senare frågan kan vara en motsvarande status eller ett helt annat angreppssätt, till exempel att använda VSTS test cases i stället för statusen Ready for Testing.

De två verktygen hanterar också länkning på olika sätt. Det som kan vara fälten Epic Link och Parent i Jira ersätts i VSTS av länkarna Parent och Child. Några länktyper som ofta finns i Jira saknas också som standard i VSTS, exempelvis Blocked by och Caused by.

Anpassningar
VSTS-processmallar kan naturligtvis anpassas i stor utsträckning för att likna Jira. Vid någon punkt handlar utmaningen om att hitta en balans mellan igenkänning och att utnyttja det nya verktyget fullt ut. Generellt innebär det att acceptera några av de standardiserade arbetssätt som VSTS erbjuder.

Det första steget i en migrering från Jira till VSTS är att granska och förstå nuvarande arbetssätt – och vilket syfte de fyller. För att göra det behöver du ha en god förståelse för vad VSTS erbjuder. Därefter kan du anpassa era arbetssätt så att de passar det nya verktyget bättre.

Med detta i åtanke kan vi välja lämplig VSTS-mall och sedan avgöra om och hur vi vill anpassa den. Därefter definierar vi nödvändiga mappningar och transformationer mellan entiteter, namn och värden i Jira och VSTS.

I grundscenariot fokuserar vi främst på hur följande ska mappas:

1. Ärendetyper

2. Länktyper

3. Tillstånd

4. Mätfält (t.ex. prioritet, story points, arbetsinsats och återstående arbete)

5. Organisering av backloggen, exempelvis sprinttilldelning och prioritering

Implementering av Jira till VSTS

Som tur är erbjuder både Jira och VSTS API:er som vi kan bygga vidare på för att automatisera processen.

Enligt vår erfarenhet är den största utmaningen vid en flytt från Jira till VSTS att återskapa och simulera historiken. Jira ger dig tillgång till ändringar i fält, länkar och bilagor, vilket tillsammans med API-slutpunkten för åtkomst till kommentarer gör att vi kan skapa en simulering av ett ärendes historik, ändring för ändring.

Utmaningar

Att återskapa historiken och simulera ändringarna på detta sätt medför ett par utmaningar:

• Vi måste ignorera de regler som VSTS tillämpar (via ett API-alternativ) för att kunna genomföra ändringar och utge oss för att vara en annan användare. Detta påverkar på ett subtilt sätt hur väl verktyget känner igen dessa små genvägar när de visas i gränssnittet eller i rapporter. Eftersom reglerna för de arbetsflöden som stöds inte alltid är desamma blir detta extra viktigt.

• Bilagor och andra artefakter från tidigare ändringar kanske inte längre är tillgängliga.

• Jira använder ett annat API för att komma åt renderade fält. Det innebär att vi kan simulera ändringar i dessa fält, men endast det senaste tillståndet renderas som i Jira.

Vi måste ignorera de regler som VSTS tillämpar (via ett API-alternativ) för att kunna genomföra ändringar och utge oss för att vara en annan användare. Detta påverkar på ett subtilt sätt hur väl verktyget känner igen dessa små genvägar när de visas i gränssnittet eller i rapporter. Eftersom reglerna för de arbetsflöden som stöds inte alltid är desamma blir detta extra viktigt.

Bilagor och andra artefakter från tidigare ändringar kanske inte längre är tillgängliga.

Jira använder ett annat API för att komma åt renderade fält. Det innebär att vi kan simulera ändringar i dessa fält, men endast det senaste tillståndet renderas som i Jira.

Om det finns länkar till externa artefakter måste dessa vara tillgängliga från VSTS för att ge samma nivå av integration i gränssnittet. Om du har en länk till en commit i ett Git-repo på Bitbucket behöver du också migrera själva repot till VSTS om du vill kunna länka till det från ett migrerat Work Item. Annars blir det bara vanlig text, vilket kan vara en acceptabel kompromiss.

• Räkna med att ändringar i vissa fält kan utlösa ändringar i andra fält, exempelvis State och Reason. Detta kan bli komplext att simulera med tanke på alla möjliga kombinationer av ändringar.

Sammanfattning

Trots utmaningarna och vissa kompromisser kan du uppnå god överensstämmelse vid migrering från Jira till VSTS. Ett sätt är att inledningsvis isolera de migrerade ärendena från resten av projektet med hjälp av Areas. Det möjliggör viss manuell massredigering samt partiell eller stegvis migrering av projektdata. Den största utmaningen är dock inte själva datamigreringen, utan anpassningarna av teamens arbetsflöden för processuppföljning.

Om du vill genomföra migreringen själv följer du helt enkelt processen ovan. Om du stöter på problem eller utmaningar, tveka inte att kontakta oss. Vi på Solidify har expertis och kunskap om båda systemen och hjälper dig gärna.

Vilket system arbetar du med? Har du övervägt att migrera från det ena systemet till det andra? Berätta gärna i kommentarerna nedan!