Så migrerar du från IBM Rational Synergy till Git

Historien bakom IBM Rational Synergy

IBM Rational Synergy är ett klient-serverbaserat versionshanteringssystem som har utvecklats från ett system för versionshantering av enskilda filer på 90-talet till ett ärendehanteringssystem med ett förändringshanteringssystem som kallas Change ovanpå. Genom åren har det haft olika namn (Continuus, CM/Synergy och senast Rational® Synergy) och ägts av olika företag, för att slutligen hamna hos IBM® under varumärket Rational®.

Under 2000-talet hade systemet några styrkor som gav det genomslag på marknaden. För det första är det ett uppgiftsbaserat system för konfigurationshantering, vilket är ett steg upp från system som CVS. I Synergy kan du tilldela utvecklare uppgifter som ändrar och lägger till filrevisioner och slutligen slutföra uppgiften för en viss release.

För det andra har det konceptet repositories, vilket passar bra för större organisationer där många team levererar komponenter till produktlinjer.

För det tredje kunde det utökas med Rational Change för att implementera processer för ändringshantering av mjukvara, anpassade hierarkier, egenskaper och livscykler.

IBM Rational Synergy närmar sig slutet av sin livscykel

Verktyget underhålls, men har inte fått några funktionsuppdateringar på många år och närmar sig därför slutet av sin livscykel. Enbart av detta kritiska skäl bör en snabb migrering till ett nytt system som Git finnas på IT-agendan.

Dessutom är systemet mycket långsamt att använda, kräver mycket manuellt arbete för enkla merge-operationer, är utformat för release-brancher som lever länge och är komplext att förstå. Allt detta kan minska utvecklingsteams effektivitet.

Min erfarenhet är att team och organisationer utvecklar ett tankesätt som går ut på att ”inte röra det”. Det innebär att de inte ens utvecklar eller optimerar sin användning av Synergy för att möta teamens behov. Alla lever med det och hittar sätt att kringgå det. Bara detta visar att det är dags att gå vidare.

Den stora frågan är: går det att göra? Det korta svaret är ”med största sannolikhet”. Det beror egentligen på hur Synergy har använts genom åren.

Planera migreringen

Matcha datamodellerna i Synergy och Git

Synergy har en mycket flexibel modell för hur mjukvaruförändringar bygger upp en revision. Detta innebär utmaningar vid migrering från Synergy till Git. Datamodellerna är helt olika. Här är de största skillnaderna.

Översikt över mappning av koncept

Utifrån våra erfarenheter av migrering har vi tagit fram en migreringsstrategi som sammanfattas i tabellen nedan, med en snabb bedömning följd av en detaljerad motivering.

Synergy

Git

Filer och historik

Inte direkt

Uppgifter

Inte direkt

Baselines

Inte direkt

Releaser

Nej

Projekt och revisioner

Repository, commits och taggar

Delprojekt

Submodules

Anpassade attribut

Nej

Filer och deras historik – migreras inte direkt

Filer i Synergy har en egen revisionshistorik och kan vara intressanta att migrera, men filrevisioner finns inte som egna revisioner i Git.

Synergy-filobjekt har typer, och beroende på typ kan filen ha olika radbrytningar samt olika beteenden för visning och sammanslagning. Detta kan till stor del implementeras i .gitattributes. En sak som fortfarande behöver hanteras uttryckligen är exekveringsbitar, eftersom de inte sätts automatiskt i Git.

Var medveten om befintliga .gitignore- och .gitattributes-filer i importerad källkod, eftersom de kan orsaka oavsiktliga beteenden om de finns med under migreringen. Sammanslagningar utförs på filobjektsnivå.

Uppgifter – migreras inte direkt

Uppgifter skulle vara det idealiska objektet att migrera, eftersom en uppgift är en enskild ändring, liknande en patchfil i Git. Det innebär att den saknar en föräldrarelation. De migreras inte, men listas i commit-meddelanden och annoterade taggar.

Baselines – migreras inte direkt

Baselines, även kallade baseline-objekt, kan inte migreras som de är, eftersom de bara är behållare för metadata och länkar till projektrevisioner, uppgifter och Change Objects. Det närmaste vi kommer i Git är annoterade taggar, där baseline-informationen läggs till som annotation. Baselines är ett relativt nytt koncept och blev obligatoriska först i version 7.x, så de är inte en tillförlitlig källa för migrering.

Releaser – migreras inte

Releaser liknar på sätt och vis grenar, men används vanligtvis som långlivade release-grenar. De visas endast i namngivningen av den annoterade taggen.

Projekt och projektrevisioner – migreras

Projekt och projektrevisioner i ett statiskt tillstånd är det närmaste vi kommer en commit i Git. De statiska tillstånden för projektrevisioner är: integrate, test, sqa och released. Detta är en reproducerbar revision som baseras på en tidigare revision, kallad en project baseline. Projektrevisionerna är det bästa migrationsobjektet eftersom de innehåller källkodens revision och har historikrelationen.

Ett Synergy-projekt bör som standard mappas till ett Git-repository. Revisionsnamnet är vanligtvis samma som releasen, build-numret eller ett ID som mjukvaruorganisationen kan identifiera senare. Revisionsnamn eller ID:n mappas till Git-taggar. Efter migreringen kan du hitta motsvarande mjukvarurevision i Git med samma namngivning som i Synergy.

Projektnamn och revisioner har betydligt färre begränsningar än Git för namngivning av repositories och taggar. Det innebär att du sannolikt måste ersätta mellanslag och ovanliga tecken med bindestreck eller understreck, och troligen även göra projektnamnen enhetligt gemena.

I Synergy kan flera projekt ha samma namn, vilket hanteras genom instansattributet. Hur dessa ska migreras bör styras av varför duplicerade projektnamn finns. Det kan vara så att det finns ett annat projekt i repository-hanteraren, eller att historiken för alla instanser har samma Git-repository som mål.

Det finns inget koncept för sammanslagningar på projektrevisionsnivå, eftersom en projektrevision endast kan ha en förälder.

Om projektrevisionerna inte representerar revisionerna, byggena eller releaserna, eller om de inte finns alls – innebär det att en migrering inte är möjlig?

Nej, inte nödvändigtvis. Mjukvaruorganisationer har vanligtvis release notes eller bill of materials. De anger baseline-revision, delprojektsrevisioner och uppgiftslistor. I så fall går det att återskapa revisionen och migrera den till Git.

Delprojekt – migreras

De kan direkt mappas till submodules i Git, eftersom datamodellen är densamma. Ett projekt kan ha ett annat projekt tillagt som ett delprojekt i en specifik revision. Det resulterar i en katalog i arbetsytan. Samma sak gäller i Git.

Anpassade attribut – migreras inte

De kan skapas för vilket objekt som helst i Synergy-databasen. De ger utvecklingsprocessen en särskild innebörd som kan vara svår att återskapa i Git. Det handlar inte så mycket om själva migreringen, utan om hur utvecklingsprocessen anpassas till att arbeta i Git.

Ovanstående visar att även om det kanske inte finns någon direkt en-till-en-mappning från Synergy till Git, kan du göra rimliga val som gör migreringen möjlig.

Så migrerar du

Eftersom projekt och deras revisioner är enheten för migrering ska vi titta lite närmare på hur migreringen genomförs.

Projekt

Först behöver du ta reda på vilka projekt från vilka databaser du vill migrera. Du kanske redan har en uppfattning om vad som ska migreras, men jag rekommenderar att du söker i databaserna efter projekt för att undvika att missa några.

Databaserna kan ha funnits längre än personerna som i dag arbetar i teamen. Du behöver utvärdera projekten för att avgöra om de ska migreras eller kan hoppas över. Vissa projekt har delprojekt, och du måste avgöra hur dessa ska migreras. Antingen bör de bevaras som en submodule eller bli en underkatalog.

Påverkan från filrevisioner

Arbete i ett klient-server-baserat SCM har ofta lett till mönster där artefakter, beroenden och verktyg lagras i källkoden. Det passar inte särskilt bra med ett distribuerat versionshanteringssystem som Git, eftersom du som standard har med dig hela historiken över commits och filer.

Repositoryts storlek i sig, men även storleksökningen per revision, ger en första indikation på om repositoryt är hållbart på lång sikt. Åtgärder kan vara att ta bort filer, lägga dem i en artefakthanterare, använda Git Large File System (LFS) eller submodules. Det är svårt att på förhand säga vilken lösning som är bäst för varje fil eller område. Den utvärderingen och de åtgärder som behövs bör beslutas inom organisationen.

Metadata – filer, uppgifter och baselines

Som nämnts ovan kan filer, uppgifter och baselines inte migreras till Git som de är, men de innehåller mycket relevant information. Baseline-objektet innehåller denna information och kan läggas till i en annoterad tagg tillsammans med commit-meddelandet. Det är bra, eftersom informationen både är sökbar i Git och kan tolkas av Git repository managers. Det ger dig en spårbarhetsbrygga från Synergy till Git. Du kan migrera Synergy-uppgifter och Rational Change-problem till ditt uppgiftshanteringsverktyg. Uppgifterna kan innehålla information om ansvarig, release, beskrivning och fillistor.

Repository managers och uppgiftshanteringssystem har vanligtvis integrationer, så att du kan referera till uppgifter i commit-meddelanden. Då går det att använda denna metod för att länka ihop de migrerade projektrevisionerna med uppgifter i uppgiftshanteringssystemet. Det ger god spårbarhet för historiska revisioner. Jag har tidigare genomfört en migrering till BitBucket och Jira. Synergy-uppgifter migrerades till Jira som stories tillsammans med FixVersions och komponenter.

Iterationer och verifiering

Erfarenhet genom åren säger mig att du behöver justera migreringsverktygen några gånger för att få allt rätt. Det är en iterativ process. Vissa beslut behöver fattas kring processer och struktur. Med stor sannolikhet byter du bilens motor medan du kör, så räkna med att behöva öva på migreringen flera gånger.

Migreringen bör verifieras både ur ett tekniskt perspektiv och ett processperspektiv

Tekniskt sett kan du jämföra filer och strukturer mellan en revision som hämtats från Synergy och en tagg som hämtats från Git. Kan vi bygga och verifiera mjukvaran? Kan du generera dokumentation, skapa artefakter och releases?

När det gäller processen behöver du gå igenom en fullständig utvecklings- och leveranslivscykel i Git för att se att du kan arbeta utifrån Git-basen.

Genomföra migreringen

I de föregående avsnitten lyfte jag fram utmaningar och möjliga lösningar till följd av de olika datamodellerna. Många av dessa delar är implementerade i vårt open source-verktyg 2git, som har använts för ClearCase- och Synergy-migreringar.

Migreringen har två huvuddelar. Den första är att flytta källkoden från Synergy till Git utan modifieringar och optimeringar. Den andra är att optimera Git-repositoryt och lägga till beroenden.

Synergy till Git:

1. Kör 2git med drivrutinen ccm2git. Resultatet är Git-historik som inte är optimerad och saknar submodules.

2. Jämför filer och struktur mellan samma revision från Synergy och Git

3. Bygg mjukvara från Git

4. Utvärdera resultatet

5. Genomför en repository-analys för att identifiera filer som ska tas bort och LFS-konfiguration för fas 2. Ett alternativ är att använda git-repo-analyser för att hitta de filer som har störst påverkan på Git-repositoryt.

Upprepa dessa steg tills du är nöjd med migreringen.

Git-optimering:

1. Uppdatera .gitignore och .gitattributes utifrån repository-analysen i fas 1

2. Lägg till beroenden i ett artifact management-system

3. Kör 2git med git2git-with-ccm-flavour. Resultatet blir en Git-historik som är optimerad med submodules.

4. Jämför filer och struktur mellan samma revision från Synergy och Git

5. Lägg till beroenden och verktyg som saknas i Git

6. Uppdatera 2git-verktyget utifrån dina beslut så att det hämtar beroenden och verktyg

7. Bygg mjukvara från Git

8. Utvärdera resultatet

Upprepa stegen ovan tills du är nöjd

Produktionssättning

Delta- och partiella migreringar

För större organisationer kan det vara svårt att utbilda teammedlemmar i Git och nya processer. I sådana fall kan partiella migreringar vara en fördel. De kan göras antingen på projektnivå eller baserat på Synergy-releaser.

2git kan hantera delta-migreringar och migrerar endast de projektrevisioner som saknas till Git, vilket gör processen flexibel och mindre av en ”big bang”. Jag rekommenderar att du börjar med projekt på högsta nivån. Dels för att ett sådant projekt inte har några andra Synergy-projekt som är beroende av det, dels för att du tidigare kan verifiera att du kan skapa produktreleaser med den nya verktygskedjan, vilket minskar risken i mjukvaruprojekten. Subsystemen kan fortfarande skapa releaser i Synergy, och Git-taggen/commiten blir tillgänglig för integration efter ytterligare en körning av 2git.

Definiera en branching-strategi

Som nämnts skiljer sig Synergy och Git åt när det gäller releaser och branches. I båda miljöerna levererar en utvecklare ändringar till en release respektive branch, men i Synergy finns varken en default branch eller konceptet trunk based development. Du kanske redan har hanterat detta i Synergy, vilket är bra. Då kan du direkt dra nytta av Gits arbetssätt genom att ange samma branch som default branch.

Det finns många sätt att hantera Git branches, och det är svårt att rekommendera en väg utan djup kunskap om ert nuvarande arbetssätt och era begränsningar.

Jag föreslår att du undersöker den migrerade historiken i Git för att få en god förståelse för hur era mjukvarutillgångar har utvecklats över tid. Du kan tydligt se hur projektrevisionerna och deras baselines har utvecklats över tid, och var det finns förgreningar i historiken.

Varje förgrening visar en branch, men du är bara intresserad av de potentiellt aktiva branches som kommer att få commits inom den närmaste framtiden. Du kan alltid skapa fler vid behov.

Uppföljning

Du har nu gått över till Git och kan dra nytta av fördelarna, men det kan vara svårt att ändra invanda arbetssätt.

Till exempel fortsätter organisationer ofta att utveckla på release-brancher. Med Git kan du i stället utveckla funktioner på master-branchen och bara skapa release-brancher när de behövs för mognadsprocessen. Du behöver arbeta aktivt för att gå från tidig till sen branching, så att du kan dra nytta av en mindre divergerande kodbas.

Merging är dyrt i Synergy och därför mergar du sällan tillbaka release-brancherna till mainline. Det kan till och med hända att ändringarna inte mergas alls. I stället ombeds utvecklare att implementera samma ändringar på flera brancher.

Nu kan du skapa en branching-strategi som möjliggör detta på ett automatiserat sätt. Git är både snabbt och tillförlitligt när det gäller merging. Det kan till och med implementeras i din Continuous Integration-plattform. Jag föredrar Git Phlow eftersom det är utformat så att du bara behöver implementera ändringar en gång, medan automatiseringen sprider ändringen till mainline via enkla merges.

Slutsats

En Synergy-migrering känns ofta skrämmande på grund av omfattningen och de äldre verktygen runt omkring, men med rätt kunskap och kompetens är den fullt möjlig. Erfarenhet hjälper också. Vi har hjälpt stora globala organisationer med detta.

Vi kan också hantera din GitLab åt dig genom vår Eficode ROOT managed service.