Migrering och transformation: att slå två flugor i en smäll

Om möss och migreringar

Transformationer är ännu mer riskfyllda eftersom de möter motstånd mot förändring. Vem vid sina sinnens fulla bruk skulle då genomföra en migrering och en transformation samtidigt?

Faktum är att vi på Eficode alltid rekommenderar att ta det djärva steget och använda varje migrering som en möjlighet att genomföra förändringar – uppgradera till bättre verktyg, förbättra era processer, stärka er säkerhet och så vidare. Varje migrering som inte innehåller åtminstone ett inslag av transformation är en missad möjlighet att förbättra hur ni bedriver er verksamhet.

Här är några saker som du nästan alltid kan förbättra när du migrerar:

• Automatisering: I en stor organisations processer kan man nästan aldrig ha för mycket automatisering.

• Säkerhet: Med tanke på det ständigt föränderliga cybersäkerhetslandskapet är det osannolikt att du någonsin når en säkerhetsnivå som är för hög.

• Processoptimering: Identifiera flaskhalsar eller redundans i arbetsflöden och effektivisera dem för snabbare leveranser och bättre samarbete.

• Kulturell förändring: Uppmuntra nya arbetssätt, främja innovation och samordna team så att de effektivt kan använda nya metoder och verktyg.

Låter det lockande? Det är väl dyrare, eller hur? Både ja och nej. Att planera för förändring kräver alltid arbete och resurser, men det är också en investering i framtida produktivitetsvinster. Att kombinera migrering och transformation innebär dock inte nödvändigtvis att arbetet blir mer komplext. Med en bra bedömning av er nuvarande situation, en tydlig förståelse för det önskade slutläget, rätt resurser och god framförhållning kan en migrationstransformation hjälpa er att förbättra organisationens arbetssätt och resultat.

I en av våra senaste migrationstransformationer hjälpte vi en kund att nå en högre mognadsnivå inom Platform Engineering, förbättra sina system för identitets- och åtkomsthantering samt implementera verktyg för självbetjänad migrering i plattformen – allt med minimal nedtid för deras kritiska system. Vi vill dela den här berättelsen med alla våra kunder.

Migrering som en del av Platform Engineering

Kunden i fråga hade en utgången Bitbucket Server som behövde migreras till GitHub Enterprise Cloud med Enterprise Managed User snarast möjligt.

För Bitbucket fanns varken centraliserad åtkomsthantering eller någon policy för styrning. Dessutom utfördes allt arbete med att administrera produkten och hantera användare manuellt. Kort sagt var det en typisk röra: Ett verktyg som hade försummats i flera år hade nått ett läge där det inte bara var en flaskhals för utvecklingsarbetet, utan också medförde risker för compliance och säkerhet.

Kundens önskade slutläge var att flytta till GitHub och samtidigt genomföra grundläggande förändringar i hur de strukturerar sin kodbas och hanterar användare:

• Migrering från deras förfallna Bitbucket till GitHub Enterprise Cloud med Enterprise Managed Users.

• Införa C4, ett ramverk för mjukvaruarkitektur.

• Implementera en IAM-modell baserad på Zero Trust-koncept som Role Based Access Control, Just Enough Access och fullständig hantering av identiteters livscykel.

Med över 4 000 repositories och 58 utvecklingsteam var det mycket förändring att genomföra på en gång. Men ett år efter att arbetet påbörjades har kunden nått det önskade slutläget – och inte bara nått det, utan gjort det smidigt och utan några större katastrofer.

Självbetjänad migrering

Med tanke på komplexiteten i migrerings- och transformationsprocessen ville vi uppnå så mycket standardisering och automatisering som möjligt. För att göra det beslutade vi att använda kundens befintliga verktyg (Backstage, Platform API, Entra ID och MyAccess). Det befintliga migreringsverktyget integrerades med de kundhanterade verktygen för att skapa en upplevelse för ”självbetjänad migrering” i kundens interna utvecklingsplattform, Backstage. Slutanvändarna behövde ange nödvändig information i ett GUI i Backstage för att starta en End-to-End-pipeline som hanterade hela livscykeln för migreringen av deras repository. Den automatiserade migreringspipelinen hanterade sedan allt från början till slut:

• Migrerade git-repositories och tillhörande metadata (issues, PR:er, bilagor osv.) från Bitbucket till GitHub i enlighet med C4-modellen.
  Satte alla brancher i käll-repositoryt i skrivskyddat läge under migreringen.
  Löste konflikter löpande.
  Migrerade innehåll i large file storage.
  Tog bort användaråtkomst för alla användare och grupper i Bitbucket-miljön (effektiv nedlåsning av källmiljön).
  Bytte namn på repositoryt genom att lägga till ett prefix i repo-namnet innan det flyttades till Archival-projektet (t.ex. PRJ.<repo_name>).

• Validerade repositorydata efter migreringen för att säkerställa dataintegriteten (genom att verifiera den senaste commit-hashen för varje branch mellan käll- och mål-repositories).

• Skapade GitHub-team och Entra ID-grupper enligt RBAC, som sedan provisionerades i GitHub-miljön för att smidigt migrera användare till den nya miljön.

• Loggade hela processen i Grafana.

• Lade till rätt inställningar i GitHub-repositoryt som en del av processen efter migreringen.

• Sätt alla grenar i källkodsförrådet i skrivskyddat läge under migreringen.

• Konfliktlösning i realtid.

• Migrering av innehåll i Large File Storage.

• Tog bort användaråtkomst för alla användare och grupper i Bitbucket-miljön (effektiv nedlåsning av källmiljön).

• Byt namn på kodförrådet genom att lägga till ett prefix före namnet innan det flyttas till Archival-projektet (t.ex. PRJ.<repo_name>).

Före produktionsmigreringarna testades och dokumenterades hela migreringsprocessen noggrant för att skapa trygghet inför migreringar i stor skala. Support fanns tillgänglig under migreringsprocessen för att felsöka eventuella problem som en extra säkerhetsåtgärd. Under processen uppstod inga betydande fel, endast några få problem identifierades (och samtliga åtgärdades inom 24 timmar).

Resultatet blev att kunddata inte bara migrerades från ett äldre verktyg till nya GitHub Enterprise Cloud, utan att allt genomfördes med i princip nästan ingen nedtid eller störning.

Samtidigt genomfördes en kulturell förändring. Strikta åtkomstkontroller infördes för att begränsa åtgärder som att skapa kodförråd till tjänstekonton (SA) och organisationsadministratörer, vilket etablerade en centraliserad styrningsmodell baserad på Zero Trust-principer.

Användare måste nu skicka in förfrågningar via MyAccess för att utföra åtgärder kopplade till kodförråd. Borttagning av kodförråd begränsades och kan endast göras genom en formell process för begäran och granskning. Åtkomst till kodförråd måste också begäras för att säkerställa att behörigheter hanteras effektivt. Sammantaget är allt automatiserat, centraliserat, övervakat och loggat.

Efter migreringen

Projektet levererade det som utlovades: Kunddata flyttades från Bitbucket till GitHub i tid och utan störningar för verksamheten. Dessutom genomfördes ett stort antal lika viktiga förändringar.

Förbättrad säkerhet och regelefterlevnad

Processerna för identitets- och åtkomsthantering gjordes om helt. De bygger nu på Zero Trust-principer. Tillsammans med automatiseringen av IAM-processer stärker de organisationens säkerhet och bidrar till att upprätthålla efterlevnaden av relevanta ramverk, såsom ISO 270001 och NIS2.

Automatisering av IT-processer

En viktig del av migreringsprocessen var att bygga automatisering kring användarprovisionering och konfigurering av de resurser som behövs för utvecklingsarbetet.

De nya automatiserade processerna främjar enhetlighet, effektivitet och säkerhet. De höjer standarden för DevSecOps och frigör DevSecOps-teamet så att det kan fokusera på uppgifter med högt värde i stället för att upprepa rutinuppgifter som att skapa kodförråd, hantera förfrågningar om användarhantering och liknande.

Organisatorisk förändring

Migreringen användes för att förändra synsättet på ramverket för mjukvaruarkitektur, förbättra utvecklingsmetoderna och göra den omfattande kodbasen mer hanterbar och lättare att förstå.

Ett djupare fokus på Platform Engineering

Migreringsprocessen byggde på befintliga verktyg för utvecklarplattformen (Backstage, Platform API), som utnyttjades fullt ut. Som följd nådde organisationen en ny mognadsnivå inom Platform Engineering.