För dig som står inför utmaningen att migrera från en uppsättning DevOps-verktyg till en annan har jag samlat de mest användbara lärdomarna, med gott om exempel från verkligheten. Lärdomar från både den svåra och den enkla vägen, omsatta i konkreta råd.
Kalle Sirkesalo
Field CTO
Kalle sits at the intersection of executive strategy and engineering reality. He works directly with CTOs and engineering leaders to translate business pressures — speed, compliance, ROI — into technical decisions that actually hold. His job is to make sure what we recommend is something your organization can actually execute.
Innehållsförteckning:
Vilken typ av migrering planerar vi?Vilka KPI:er definierar en lyckad migrering?Vad ska migreringsteamet ansvara för? Hur migrerar teamen själva till den nya miljön? Hur fördelar vi kostnaderna?Ett exempel: en fullständig migrering
Funderar du på att migrera till nya DevOps-verktyg? Även om du inte gör det i dag kanske du gör det en dag.
I dag finns det fantastiska allt-i-ett-alternativ som GitHub, GitLab och Atlassian. Men precis som många andra kanske du tycker att hela frågan om migrering är lite svår att få grepp om.
Vad som krävs
Så gör du
Var du ens ska börja
Här på Eficode har vi börjat se en stor förändring i kundernas synsätt:
För 10 år sedan, när vi startade vår plattform Eficode ROOT, behövde vi förklara varför du skulle vilja ha DevOps.
För 5 år sedan behövde vi förklara varför du borde centralisera dina DevOps-verktyg.
I dag berättar vi hur du centraliserar dina verktyg.
Efter mer än 15 år med DevOps har vi insett att inte alla förstår hur svårt det är att byta från en CI-lösning till en annan.
Vi vill ge dig en bättre förståelse för hur du sparar tid och arbete vid en migrering och undviker några av de vanligaste fallgroparna. I det här blogginlägget delar vi med oss av åtta värdefulla saker att tänka på.
Vårt mål är inte att ge fullständiga svar, utan snarare att lyfta de frågor din organisation bör ställa. De ”okända okända”: det du behöver veta för att förstå vad du inte vet.
Läs vidare för att hitta rätt frågor och de beredskapsplaner som behövs för en smidig och lyckad migrering.
‘migrations never fail due to technical problems’
1. Kulturen är inte redo – än
Migreringar innebär tekniska utmaningar, men det är aldrig därför de misslyckas.
De misslyckas på grund av människor och kultur. Många tror att det bara handlar om en uppsättning verktyg, men den verkliga utmaningen är att hantera förändring. Förändringsledning är kärnan i varje företags kultur. Vissa gör det bara bättre än andra. Så varför är detta så viktigt? Låt oss ta ett verkligt exempel.
Ett exempel: att flytta ditt versionshanteringssystem, GitHub Enterprise, från on-premises till Cloud
Det är en av de enklaste migreringarna du kan göra. Du har gjort allt och inget förändras i processen för användaren. Vissa delar går faktiskt enklare än du trodde, och du behöver inte oroa dig för dina migrerade konfigurationer. Men varje GitHub-användare måste ändra en sak i sin miljö: repositoryts URL. Alla CI/CD-jobb använder också denna URL.
Så vad gör du? Skriver om DevOps-pipeline-logiken för att stödja detta?
Ja, det går att göra, och det har vi gjort. Men hur blir det med hash-kontrollerna för SSH-autentisering? Du kanske tror att de fungerar, men tyvärr inte – du måste godkänna dem manuellt.
Det här kommer att kräva mycket vägledning och pådrivning av teamen. Det blir sannolikt diskussioner som: ”Vem betalar för den förlorade tiden?”, ”Vi missade en viktig milstolpe” och så vidare. Du har skapat mycket misstro i organisationen eftersom du misslyckades med att hantera den enda enkla uppdatering som krävde att användarna agerade!
Det här handlade bara om att migrera Git-repositories. Hur tror du att personer som använder Jira känner när du vill flytta dem till GitLab?
Tips: När du genomför migreringar bör du kartlägga integrationspunkterna så att du får en lista över berörda system och URL:en till det repository som ska uppdateras.
För att lösa detta brukar vi ge våra kunder följande råd:
Samla alla berörda parter och informera dem i god tid, så att du kan ge vägledning och verksamhetsstöd. Seniora medarbetare kan förklara varför migreringen behövs.
Kontinuerlig kommunikation är avgörande hela vägen – även efter underhållsfasen.
Verksamhetsstöd kräver förståelse för drivkrafterna. Migreringen bör bygga på ett väl underbyggt business case och tydliga prioriteringar. Om din chef frågar: ”Vad sparar vi på det här?” bör du kunna ge ett konkret svar.
Vi har tagit fram en kalkylator för att uppskatta besparingar. Kalkylatorn bygger på Eficodes erfarenhet och Eficode ROOT-lösningen, men ger en bra bild av vad som står på spel.
Eftersom de här diskussionerna kan vara tuffa är det ibland enklare att låta ett externt företag genomföra migreringen, så att du inte behöver bära ansvaret ensam. Vi har sett företag som inte informerar sina medarbetare och sedan ber om ursäkt när något går fel, eftersom de tror att det är lika effektivt. Men det är inte det bästa sättet att kommunicera i organisationen och leder oftast till sämre resultat än transparens. Om det tar längre tid att ordna de möten som behövs än att be de berörda parterna om ursäkt, är det förmodligen inte värt det.
2. Människor gillar inte förändring
Nu när vi har pratat om kulturella chocker i organisationen kan vi se på hur individer påverkas. Inflytelserika personer i organisationen kan vara en utmaning. Det handlar ofta om avancerade användare av verktygen, med en stark teknisk och/eller social position i organisationen. De tycker mycket om verktygen de använder och underhåller och ser därför ingen anledning att ersätta verktyg som de har lagt så mycket tid på att konfigurera precis som de vill ha dem.
Du måste göra det värt deras tid att lära sig det nya verktyget och se till att deras tidigare erfarenheter kommer till nytta.
Du behöver få dem att bli förespråkare och förändringsagenter. Gör så här:
Ta reda på vilka dessa personer är direkt
Involvera dem i de tidigaste faserna
Visa dem hur de kan lösa befintliga problem i det nya verktyget
Be om deras råd om var migreringen bör utökas härnäst.
Det här är ett mycket effektivt sätt att få dem med på tåget, så att de kan förespråka det nya verktyget för teamen. Om de förstår det kommer de att ta till sig det och inte vara rädda för förändringen. I stället blir de dina bästa ambassadörer i migreringen! Rädslan för förändring kan ofta minskas genom utbildning och samtal med befintliga användare av verktygen.
Tips: Involvera avancerade användare i beslutsprocessen så att de får möjlighet att förklara sina perspektiv.
Ett exempel: Att gå till botten med Jenkins
En av våra kunder var mycket skeptisk till om vi kunde hjälpa dem i deras arbete och med driften av deras verktyg. Vi diskuterade att avlasta dem från en del av arbetsbördan, men de ansåg att det rörde sig om väldigt lite arbete.
Vi gick igenom hur det nya verktyget, Jenkins, fungerar och hur de måste kontrollera varje plugin. Om något går sönder under natten måste de vakna och få det att fungera igen. Vi gick igenom systemet och hur mycket extra arbete de behövde göra varje dag för att hålla det igång.
Det de egentligen ville var att skapa en bättre testarkitektur för sitt system, i stället för att dagligen släcka bränder och åtgärda fel. Vi diskuterade hur vi tidigare har löst de här problemen. Därefter frågade de om vi även kunde ta hand om underhållet av några av deras andra system, så att de i stället kunde fokusera på att skapa och skriva kod. Att bli lyssnade på var det avgörande steget för att hjälpa dem att inse var de befann sig tidigare.
3. Fokus ligger inte på rätt frågor
Vi har hittat våra ambassadörer och vår kultur börjar bli mer positiv till migreringen. Då borde vi väl vara redo att köra, eller hur? Låt oss bara ta itu med de där irriterande tekniska frågorna!
Nej, inte än. Vi behöver en tydlig plan.
Vi måste besvara migreringens fem frågor, som kommer att avgöra om vi lyckas. Det handlar om att få alla att enas om målen för migreringen. Vi gör samma sak som i mjukvaruprojekt: vi behöver stanna upp och säkerställa att alla förstår varför vi gör detta och vad vi arbetar mot.
Frågor att ställa under migreringsplaneringen:
Vilken typ av migrering planerar vi?
Vilken data förväntas vi migrera?
Förväntar vi oss en helt automatiserad migrering för utvecklarna, eller förväntar vi oss att de själva gör många ändringar?
Migrerar vi till en annan instans av samma verktyg, eller till ett helt nytt verktyg?
Om det är ett nytt verktyg, vad förväntar vi oss att förändra i våra nuvarande arbetssätt?
Vilka KPI:er definierar en lyckad migrering?
Vi behöver fastställa våra KPI:er för en lyckad migrering.
Vad ser vi som framgång: att alla användare har migrerats? Att teamen är nöjda med de nya verktygen? Kortare cykeltider? Lägre kostnader?
Hur utvärderar vi dessa och var sätter vi målnivån?
När du har besvarat dessa frågor kan du fråga hur migreringsteamet, som ansvarar för att nå dessa KPI:er, ska sättas samman. Den svåraste delen av teamarbete är att få alla att arbeta mot samma mål. När du sätter KPI:er bör du därför tänka på hur de påverkar olika intressenter.
Om du satsar på högsta kvalitet bör du välja KPI:er som påverkar migreringens kvalitet, till exempel:
Antal supportärenden (med målet noll)
Hur mycket arbete som krävs av slutanvändarna (vilket bör vara minimalt)
Påverkan på verksamheten
Användbarheten i det nya systemet (mätt med en användarnöjdhetsundersökning).
Om du satsar på lägsta kostnad bör du använda KPI:er som mäter:
Projektets längd
Funktionsparitet med de tidigare systemen som används
Ärenden som fortfarande är öppna två veckor efter migreringen.
Dessa påverkar vad migreringsteamet kommer att optimera för.
Vad ska migreringsteamet ansvara för?
Nu när du vet vad migreringsteamet kommer att prioritera är det dags att fråga: ”Vad ska teamen behöva göra?” Kartlägg detta utifrån dina KPI:er. Om du satsar på lägsta kostnad blir det manuella arbetet mer omfattande än om du lägger sex månader på att utveckla verktyg för att migrera alla på en gång.
Fundera därför noga på vad du kan förvänta dig av dina team.
Hur migrerar teamen till den nya miljön?
Vi ser ofta stora investeringar i uppgifter som teamen mycket enkelt skulle kunna göra själva, och som det kanske till och med är rimligt att de gör. Till exempel att flytta CI/CD-jobben till den nya miljön och samtidigt rensa upp gammalt skräp.
Det är vanligtvis inte meningsfullt att migrera något som inte kommer att användas, särskilt inte om det aldrig ens fungerade som teamet förväntade sig. Men ibland vill teamen att hela deras CI/CD flyttas på en gång. De vill inte röra något som fungerar.
Fundera därför på hur ni kan belöna teamen och skapa incitament för dem att migrera. ”Den här tjänsten stängs ner om sex månader” är alltid ett giltigt påtryckningsmedel, men är det effektivt i vår organisation?
Jag har sett många organisationer som informerar sina användare om att en tjänst kommer att avvecklas, men eftersom personerna vet att avvecklingen inte kommer att ske fortsätter de att använda de gamla lösningarna. Teamen kan till och med använda miljöer som ”stängdes ner” för årtionden sedan.
Om du vill göra konsekvenserna tydliga igen: flytta kostnaden till teamen som fortfarande använder lösningen. Vanligtvis migrerar teamet då förvånansvärt snabbt till ett nytt system. Men kom också ihåg att alla organisationer är olika.
Okej, så du har KPI:er, krav och specifikationen för migreringen. Men du har fortfarande den svåraste frågan att hantera. En fråga som du med största sannolikhet inte kan besvara på egen hand och som din chef vill undvika som pesten. Men om du inte löser den kommer du att sanda din isbana.
Hur fördelar vi kostnaderna?
Du har de direkta kostnaderna för migreringen, som licenser och arbetet som läggs på den. Det är tydligt.
Men hur är det med de indirekta kostnaderna och alternativkostnaderna? Båda påverkar ovanstående, och det är därför specifikationen skapades från början. Den behövs för att förhindra att någon blockerar migreringen.
Du behöver ha en tydlig plan för hur du informerar alla team om att projektet måste genomföras. Alternativt måste du tilldela migreringsteamet de kostnader som krävs om förseningar uppstår på grund av dessa kostnader. Vem betalar för den värdefulla utvecklingstid som ni inte ägnar åt utveckling under migreringen? Det bör finnas ett tydligt svar, och det måste stödjas av hela ledningsgruppen. Åtminstone måste din sponsor förstå att frågan kommer att riktas till dem. Genom att informera alla innan de hinner ställa frågan får dina intressenter ett bättre intryck av dig.
Ett exempel: en fullständig migrering
Vid en lyckad migrering som jag genomförde för några år sedan sa kunden: ”Vi vill ha en fullständig migrering så att vi inte behöver göra någonting.” Och det var precis vad vi gjorde:
Vi förberedde skript för att uppdatera Git-repositorierna med nya URL:er
Vi såg till att Artifactory-URL-omdirigeringar automatiskt ersattes med nya, säkra omdirigeringar
Vi migrerade jobb från lokal CI/CD till molnet, testade dem och förberedde dem för att köras som tidigare. Vi förberedde också migreringen av Jira och Confluence från Oracle-databaser till Postgresql
Samtidigt flyttade vi hela infrastrukturen till AWS.
Kostnaden för detta arbete blev mycket högre än kunden förväntade sig, eftersom mycket miljöspecifik kod behövde skrivas om för att skapa URL-omdirigeringar som förhindrade att saker slutade fungera, samtidigt som all trafik konverterades från http://address:port till https://service. Det var en liten kund, så vi antog att de inte hade tid. Men efter att ha lyssnat på återkopplingen om vad som gått fel sa de:
”Vi hade kunnat ändra de URL:erna själva. Det hade gått väldigt snabbt för våra utvecklare som en del av deras vanliga arbete.” Genom att inte specificera ”vad ska teamen göra?” gjorde vi alltså mycket mer arbete än kunden förväntade sig. I dag är de fortfarande en nöjd kund som har förtroende för oss, men vi lärde oss vår läxa. Nu vägleder vi alltid våra kunder att specificera de viktiga delar som de vill att vi ska lösa åt dem, så att de också har en budget för dem.
Låt oss sammanfatta frågorna för migreringen:
Vilken typ av migrering planerar vi?
Vilka KPI:er gäller för en lyckad migrering?
Vad ska migreringsteamet ansvara för?
Vad vill vi exakt att teamen ska migrera? Finns det några incitament för eller emot migreringen?
Hur fördelar vi kostnaderna? Alla tre: direkta kostnader, indirekta kostnader och alternativkostnader.
4. Du behöver göra en omfattande omkonfigurering
När du byter verktyg kan konfigurationerna förändras drastiskt, eftersom verktygen fungerar på mycket olika sätt. Definiera därför alltid frågan ”vad kan vi förlora?” i planeringsfasen – allt kommer inte att vara enkelt att implementera på nytt. Du kan vanligtvis implementera många av funktionerna, men det kan kräva mycket arbete i förhållande till nyttan med funktionen.
Du kan till exempel vanligtvis inte återskapa behörighetsnivåer exakt, eftersom vissa verktyg har betydligt mer detaljerade behörighetsnivåer och roller än andra. Du måste i förväg mappa vilka behörigheter som ska hamna var och vilka behörigheter teamen behöver som standard.
När det gäller CI/CD finns det inget enda sätt att bygga eller driftsätta på i de organisationer jag har stött på. Jag har till och med sett organisationer som erbjuder färdiga driftsättningsjobb, men där teamen ändå arbetar på olika sätt.
Tips: skriv en övergripande sammanställning av vad ni har. Ta reda på hur många av jobben som är definierade i kod och hur många som är definierade i ett UI, om verktyget stöder UI-konfiguration av jobb.
Troligen migrerar du till ett verktyg som endast stöder as-a-code, eller så vill du migrera alla jobb till kod. Därför är det viktigt att ta reda på hur många av dem som bara handlar om att byta syntax och var du behöver lära teamet helt nya arbetssätt, eftersom de behöver förstå att CI/CD hör hemma i repositoriet.
Ta tillsammans med era ambassadörer fram bra artiklar för de vanligaste språken och användningsfallen. Förbered er också på de ännu okända utmaningarna vid massmigrering, där ni kommer att märka hur även den enklaste konfigurationsändringen kan möta hårt motstånd.
Ett exempel: Köra en Jenkinsfile-parser på GitLab
Föreställ dig ett scenario: du har allt i Jenkins-jobb och ska flytta till GitLab med hjälp av Jenkinsfile-parsern, så att GitLab kör Jenkinsfilerna på samma servrar och med samma konfiguration. Saker kommer ändå att gå sönder, eftersom allt inte fungerar i varje situation. Många jobb har till exempel historiskt byggts genom att skicka binärfiler till Jenkins master.
Om en sådan binär driftsättning används och binärfilen inte finns någon annanstans, blir den framtida lösningen med GitLab mycket svår att implementera. Det beror på att binärfiler flyttas mellan jobb på olika sätt. Därför kräver vissa jobb en total översyn. Om de består av en kedja av jobb som fungerar tillsammans, behöver de omarbetas till en pipeline. Det kan vara utmanande, eftersom det vanligtvis finns skäl till den ursprungliga designen.
Lär dig först att arbeta med de nya verktygen och fundera sedan på vad som bör göras, i stället för att ta i för mycket under migreringen. Du kommer inte att täcka alla scenarier, så fokusera hellre på det stora flertalet än på att försöka täcka alla komplexa scenarier.
Vanligtvis vill du se till att 80 % av användarna får en bra upplevelse. När det gäller resten är det därför du genomförde de tre första stegen – så att du kan navigera genom grumliga vatten utan att drunkna.
Vårt bästa tips är: ta inte i för mycket. Gör i stället generella antaganden och var beredd att lösa resten efter migreringen.
5. Ska du automatisera eller vägleda användarna?
Du har nu kartlagt skillnaderna mellan verktygen och anskaffat verktygen för din organisation. Nu är det dags att ta itu med nästa stora fråga: hur mycket ska automatiseras och hur mycket ska användarna vägledas? Den vägledande principen bör vara att påverka arbetet på rätt sätt.
Ställ därför följande frågor:
Vilka data eller funktioner behöver du ta med till det nya systemet?
Vilka data eller funktioner kan du se som ett alternativ eller ett ytterligare mål?
Vilka nya funktioner aktiverar du som standard i det nya verktyget? Fanns dessa funktioner i den gamla miljön?
Nu när du vet vad som behöver göras och vem som ska göra det, är det dags att börja arbeta med den faktiska implementationsbackloggen. Vad du vill automatisera och vad du vill skapa riktlinjer för beror på hur brett funktionen används i verktyget. Det beror också på hur lång tid det skulle ta för teamen att börja använda den. Du bör även fundera på om det finns regleringar som kräver att dessa funktioner finns på plats.
XKCD har tagit fram en bra illustration som visar hur mycket tid människor kan lägga på att effektivisera rutinuppgifter och ändå spara tid under fem år.
I en organisation med 6 000 utvecklare kan även den minsta automatisering spara ett stort antal timmar, till exempel genom att undvika trasiga URL:er och säkerställa bakåtkompatibilitet, eller genom att låta CI-pipelines automatiskt innehålla vissa funktioner.
Ju mer omfattande du kan göra det, desto mer tid sparar du. Att till exempel ändra en Git-URL i en organisation med 6 000 utvecklare kan ta 10 minuter, men för medarbetarna blir det 60 000 minuter, vilket teoretiskt innebär 1 000 timmars extra arbete.
I praktiken görs det sannolikt medan man tänker på en annan uppgift eller fortfarande läser morgonens e-post. Men bara 10 % av dessa timmar i produktivitet skulle innebära 100 timmar av förlorad arbetstid. Därför är det vanligtvis klokt att automatisera sådant som påverkar alla.
Strategier för branching och merging i Git är en annan sak som direkt påverkar dina medarbetare. Du vill därför inte använda fel strategier i varje projekt. Tänk därför på:
Hur automatiseringen kommer att påverka slutanvändaren
Var och av vem den färdiga automatiseringen kommer att användas
Hur du säkerställer att rätt inställningar replikeras till projekt
Det är också mycket viktigt att förstå vad du kan automatisera från CI/CD-agenten, runnern eller actionen. Fråga:
Vilken typ av anpassning tillåter vi?
Hur möjliggör vi det?
Vem kommer att hantera det i framtiden?
När når teamen punkten där nyttan är som störst, utan att till exempel alla regelkrav behöver vara på plats ännu?
Hostar vi dessa åt teamen, eller hostar teamen dem själva?
Vi rekommenderar vanligtvis att ni köper in expertis för att hosta dessa från en professionell tjänsteleverantör, eftersom agenter/runners/actions ofta innebär oväntade utmaningar. Att ändra dem under migreringen leder därför nästan alltid till problem.
Ett exempel:
I Windows med C# kan du autentisera med AD-behörigheter mot SQL Server-databasen. För detta behöver servern:
vara ansluten till AD, med driftsättningar som är svåra att automatisera
ha åtkomst till dessa inloggningsuppgifter, vilket väcker säkerhetsfrågor kring vem som har åtkomst till agenterna/runners/actions
Det här är sådant som kan lösas och hanteras tillsammans med teamet i förväg. På grund av komplexiteten kan agenterna/runners/actions behöva vara kvar och underhållas manuellt av teamet under migreringen, i stället för att flyttas till en autoskalande och automatiskt underhållen molnmiljö.
Försök inte åtgärda dessa pooler under migreringen (det är omöjligt). Sträva efter att hålla systemet så likt som möjligt vid de första migreringarna i stor skala och fokusera på dem efteråt. Det kräver mer arbete, men sparar tid totalt sett.
Ibland tror vi att automatisering har löst våra problem, men i verkligheten är saker aldrig så enkla. Tänk på följande påstående: Vi har redan containeriserat och dokumenterat alla våra miljöer – varför skulle vi behöva bry oss?
Det innebär troligen att ni har möjlighet att gå över till en centralt hanterad agentplattform, till exempel genom att köra allt i en gemensam Kubernetes-miljö för alla team. Men det innebär också att nätverket fortfarande behöver planeras och förberedas.
Att konvertera till Kubernetes utan att kartlägga kraven i den gamla miljön är riskabelt, även om miljön var dockeriserad. Om ni går över till centraliserade Kubernetes-agentpooler, se till att driftsätta dem i molnet när det är möjligt.
Att hosta Kubernetes on-premises för build och driftsättning är mycket dyrt, och du kan inte uppnå samma skalning som i molnet. För att minska kostnaderna och felen i miljön vill du kontinuerligt skala ned den underliggande infrastrukturen.
Automatisering är din vän, men det är inte alltid värt att automatisera allt. Fokusera på de kritiska saker som vi specificerade tidigare. Tänk: ”Kommer våra användare verkligen att behöva detta, eller kan de hantera det själva?” Om du fortfarande anser att det behövs bör du definitivt undersöka möjligheten att automatisera det.
6. Fundera på hur du migrerar artefakter
Att byta programvara för artefakthantering verkar först vara enkelt. Men att migrera dessa binärer innebär ofta mycket arbete på grund av många olika sammankopplade delar. Du behöver kartlägga vilka typer av repositories du använder, om några.
Många CI/CD-lösningar låter dig använda deras egen disk för detta tillfälligt. Det leder ofta till problem vid migrering eftersom binären inte lagras på det sätt du förväntar dig. Och om du till exempel går från statiska till dynamiska agenter, som rensar disken mellan varje build för att undvika att skräp samlas, kan du få problem.
Det innebär att det är riskabelt att migrera dessa binärer. Det räcker inte att kontrollera att de nya systemen stöder teknikerna x, y och z, utan du behöver även fråga: ”Stöder det även remotes och virtuals?” Då kan du till exempel enkelt skapa en anslutning till ett remote repository, exempelvis npm.org, och koppla det till dina andra repositories via virtuella repositories.
Fråga detta:
Hur är det med binärfilernas layout? Den kan också anpassas i många verktyg.
Har du använt releaser i binärsystemet?
Hur kommer du att använda dem i det framtida systemet?
Det är förvånansvärt mycket att reda ut innan migreringen kan börja, bland annat om verktyget har stöd för de funktioner som behövs.
URL-ändringar
Alla ändringar du gör av binär-URL:en eller var den driftsätts påverkar alla jobb som använder det binärrepository du har definierat. Att ändra URL:en påverkar alla jobb som använder den binärfilen. Det innebär att vi behöver söka efter och ersätta URL:er, eller på något magiskt sätt mappa dem i proxyservrarna, för att säkerställa att binärfilerna går att komma åt som tidigare. Tidigare har vårt team haft stora problem med att ta bort portar och lägga till https för artefakter, eftersom det är standardfunktioner för säkerhet i dagens system. Men det är inte enkelt att införa dem och samtidigt se till att CI/CD fortsätter att fungera.
DevSecOps-pipelines
Hur är det med dina DevSecOps-pipelines? Hur integreras de med det nya verktyget? Jfrog Xray fungerar till exempel bara med Jfrog Artifactory, vilket innebär att du nu behöver byta ut ditt DevSecOps-verktyg mot ett annat. Det handlar alltså inte längre om att byta ett verktyg, utan flera.
Samtidigt behöver du avgöra vilka fjärrrepositoryn du ska erbjuda, eftersom många team av olika skäl kan använda det publika internet direkt. Du bör därför sträva efter att erbjuda dem åtkomst med lägre latens från ditt system för binärhantering.
Binärlagring
Binärlagring är inte bara mer avancerade delade diskar. De har många värdefulla funktioner som kan bli ett problem om du till exempel vill migrera helt till GitLab, eftersom många av funktionerna ännu inte finns tillgängliga i själva verktyget.
Det finns alternativ, till exempel att arkivera det gamla för att spara kostnader och bara lösa problem när de uppstår. Du kan också flytta till det nya systemet och behålla det gamla, börja använda de nya funktionerna stegvis och se vilka funktioner du fortfarande behöver. Beroende på vilka funktioner som krävs kanske du kan hitta andra smarta lösningar för att bli av med det kostsamma system som du har driftat för utvecklarna.
Ett exempel: att välja en Docker-fjärrproxy
En av våra kunder bestämde sig för att flytta allt till GitLab och ta bort alla andra lösningar från sina pipelines. Det krävde omfattande utredning kring hur de kunde erbjuda binärfiler från GitLab och vilka begränsningar som fanns. Vi kom fram till att deras team använde Docker mycket och behövde en Docker-proxy.
Vår lösning var att följa GitLabs rekommendation och använda en Docker-fjärrproxy för Docker Hub, så att de kunde använda images med GitLab utan att betala licensen för det gamla systemet. På så sätt gjorde de mindre besparingar på sina DevOps-kostnader.
Jag kan inte direkt kalla det en framgång, eftersom besparingarna var mycket små jämfört med kostnaden för projektet att migrera binärhanteringen till enbart GitLab. Det kommer att ta dem flera år att tjäna in kostnaden för förändringen. Därför brukar jag ofta föreslå:
behåll programvaran för binärhantering och flytta den eventuellt bara till molnet
integrera den med S3-buckets eller liknande för att få billig lagring
gå över till en mer optimerad arkitektur för din binärhantering
Det är enklare att sänka kostnaderna inom andra områden än för licenser för binärhantering, som är relativt billiga på grund av konkurrensen inom området.
7. Äldre pipelines
Nu är du äntligen redo att börja fundera på att flytta dina äldre lösningar till nya system och få teamet att arbeta med de nya verktygen. Du har tagit dig igenom politiken och förändringarna i arbetssättet och är äntligen redo att fråga:
Hur flyttar vi de gamla verktygen till det nya systemet?
Vi hör ofta om team som flyttar från Jenkins eller Teamcity till GitLab eller GitHub för fördelarna med en enda plattform. De letar efter enkla universallösningar för detta. Det första vi frågar dem är: ”Använder ni Jenkinsfiles eller Teamcity YAML?” Svaret är vanligtvis: ”Några av våra team gör det.”
Det innebär att vi har handgjorda ClickOPS-jobb som vi skulle behöva skriva om för något av dessa verktyg. Jobben skapades när CI as Code fortfarande var ett framträdande koncept, men ännu inte hade implementerats. Därför behöver de handgjorda pipelinesen skrivas om helt, eftersom det inte finns något enkelt sätt att migrera dem till pipeline-modellen.
Förbered sedan en lista över:
vad du behöver ändra i jobben för att få dem att fungera
hur den nya syntaxen ser ut
hur Maven, NPM, Nuget eller andra pakethanterare fungerar i det nya verktyget
Du behöver ta fram demos, exempel och dokumentation för teamet under migreringen. Det hjälper dem att skriva om och åtgärda sina jobb när något börjar gå fel.
Du kan kanske migrera vissa jobb till den nya plattformen med hjälp av tillfälliga lösningar, till exempel genom att köra en Jenkins-kärna i en agent som gör det möjligt att köra Jenkinsfiles i en GitLab-runner. Det är i huvudsak bara användbart för att migrera stora mängder och bör ses som en tillfällig lösning som uppmuntrar teamen att skriva om jobben.
Omskrivning behövs för att möjliggöra SAST- och DAST-funktionalitet. Och om du inte bygger in sådana delar i jobbet:
Varför migrerar du allt till en ny plattform? Om du inte försöker dra nytta av DevOps-communityns nya framsteg, vad försöker du då uppnå?
Låt oss gå tillbaka till början av den här bloggen: om du inte har för avsikt att migrera till en ny plattform, har du verkligen ett business case eller förändrar du bara för förändringens skull?
Att migrera verktyg innebär ofta att du behöver migrera till en ny plattform och refaktorera för att kunna använda de nya funktionerna. Dessutom använder inga av verktygen liknande syntax, vilket gör det mycket kostsamt att migrera till och från produkten. Därför drar sig många företag för det. Slutresultatet är vanligtvis värt det: efter migreringen kan du enkelt flytta personer mellan verktyg och produkter, eftersom teamen arbetar i samma verktyg och processer.
När du migrerar behöver du planera hur du ska hantera och hjälpa till vid undantag, samt hur du ska följa upp vägen framåt och hålla systemen igång för dina team. Migreringar kräver vanligtvis mycket strikt projektledning och även uppföljning av:
Vem kör fortfarande sina jobb och varför?
Vad behöver vi lösa?
Vissa team kommer att säga att en funktion saknas eller att sättet den är implementerad på hindrar dem. Det finns många sätt att bygga en pipeline, och inget av dem bör innebära att skriva ett Groovy-skript med 400 rader kod bara för att lösa ett processproblem.
Försök inte lösa allt med CI/CD, utan bygg i stället en kultur av tillit. Om du inte kan lita på ditt arbete och dina steg: stanna upp och titta på vad du arbetar med och hur. Om du inte är redo att lita på dina pipelines och arbetssätt, vad kan du då lita på i din DevOps?
Börja med att diskutera funktionen med teamet och ställ frågan ”varför”.
Varför litar vi inte på våra tester?
Varför kräver detta mänsklig interaktion?
Se till att teamet får förtroende. Om inte: då arbetar du inte med DevOps.
Om du använder CI/CD för att snabba upp driftsättningar, låt de teamen stanna kvar i det verktyget. De kommer inte att förändras, oavsett vilka verktyg du ger dem. Flytta git-repositoryt och låt CI/CD vara kvar där. Att byta build-verktyg bara för att förändra teamet fungerar sällan.
Men om de är redo att förändras och ta till sig det förtroende du visar dem, är det dags att lita på dem. De klarar det.
8. Du behöver nya dashboards och vyer
Först och främst: glöm att migrera dina dashboards och vyer. De kommer inte att fungera i det nya verktyget på samma sätt som i det gamla. Gör om dem så att de passar det nya verktyget. Fundera också under migreringen på saker som: ”Behöver vi verkligen den här dashboarden som visar grönt eller rött, eller kan vi göra den mer användbar för distansarbete?”
Dashboards kan bara visa det du ber dem att visa, med den data du ger dem. Du kan inte visa data som du inte har. Ditt team behöver implementera dataflödena, så fundera på varför du vill ha varje dashboard.
Dashboards är ett tveeggat svärd. Om dina team fokuserar på att förbättra dashboardens siffror riskerar du att låta dashboarden fatta besluten åt dig.
Till exempel började vi hos en kund att mäta releaser i Jira. Kort därefter implementerade vi automatisk skapande och stängning av releaser för teamet, baserat på ärenden som flyttats till Klar under en viss period. Det gjorde att de kunde visa sina releaser i mätvärdet utan att faktiskt behöva använda funktionen. Mätvärdet ökade tiofaldigt, men det löste egentligen ingenting för teamet.
En annan nackdel med dashboards är att teamet inte tittar på dem om de inte bryr sig om dem. Så i stället för att göra allt till en dashboard, stanna upp och fundera: ”Vad behöver vi egentligen?” ”Vad försöker vi åstadkomma med det här?”
Data är bara så bra som din tolkning av den. ”Skräp in, skräp ut”, som man brukar säga. Varje gång du snabbt bygger en dashboard baserat på data kan du leda teamet på fel spår.
Jag har till exempel sett kunder göra A/B-testning där de blandade ihop sessioner och användare, och därmed förstörde testerna med enorma mängder datapunkter, i stället för att använda selektiv gruppering för att avgöra om en funktion var användbar eller inte.
Mätvärden för compliance och applikationers livscykel sträcker sig ofta över flera team, vilket är ett helt annat område för optimering. Vi tittar vanligtvis på detta i varje fas av migreringen, från förplanering till långsiktig förvaltning.
Använd inte traditionella mätvärden för mjukvaruutvecklingens livscykel för att mäta hur lyckad din migrering är. De är missvisande så länge du inte har tillräcklig täckning. Använd mätvärden som mäter användning.
Några av våra kunder trodde till exempel att de låg bra till när det gällde DevOps-verktyg, men när vi började undersöka deras DevOps-användning visade det sig att de bara använde versionshanteringsdelen i verktygsstacken. De arbetade alltså knappt med DevOps och fokuserade på fel saker för att utveckla sina verktyg. Deras mätvärden visade att det gick bra: de använde verktyget. Det var tekniskt sett sant, men du behöver använda mätvärden som stöttar teamet och arbetssätten i verktyget, inte produktanvändningen.
Några avslutande ord
Att arbeta med det här inlägget har varit en rolig upplevelse i att försöka sammanfatta drömmigreringen som ständigt tycks undfly en. Här är några sista råd.
Det kanske inte blir vackert
Jag har några gånger lyckats genomföra fantastiska migreringar, men jag skulle säga att det är väldigt sällsynt. Oftast blir de väldigt röriga, trots all kunskap jag har samlat på mig under de senaste tio åren av migreringar av DevOps-verktyg och molntjänster. Varje gång väntar en överraskning bakom kravhanteringsprocessen, som du sitter ensam och löser klockan ett på natten en lördag, med vetskapen om att testningen börjar i morgon bitti och att hela migreringen skjuts upp om det inte är klart till klockan tio. Då måste du gå igenom de senaste 36 timmarna av helvete igen. Så du fortsätter kämpa och hoppas lösa det.
Var inte rädd för att misslyckas
Ibland lyckas du, men oftare misslyckas du. Var inte rädd för att misslyckas när du migrerar. Ta till vara på lärdomarna och förbered dig bättre till nästa gång. Försök också undvika migrationsdagar på över 40 timmar. De är inte hälsosamma och verkligen inte produktiva. Kom överens med en kollega, gör bra överlämningar och se till att ha ett team med pigga hjärnor.
Ett exempel på en lyckad migrering
Avslutningsvis vill jag berätta om en migrering som gick bra.
Vi gick till mötet och kunden sa att de skulle migrera följande månad. Det behövde gå bra eftersom den gamla leverantören skulle sluta supportera programvaran om en och en halv månad. Vi gjorde en plan för produkten, som vi känner väl, förberedde miljöerna och datamigreringarna och såg till att allt var klart. Vi genomförde ett stort antal testmigreringar och kontrollerade att allt fungerade som det skulle.
På go-live-dagen började vi migreringen och DNS migrerades enligt överenskommelse. Men TTL var satt till en timme, vilket gjorde att migreringen tog en och en halv timme på grund av ett förbiseende i DNS-konfigurationen. Det uppstod inga andra problem alls, och vi var i produktion som planerat. Även med all erfarenhet och utbildning kan ett enda förbiseende tredubbla tidsåtgången för ett sådant projekt. Det gick bra och vi var glada över att vara i produktion.
Kom bara ihåg: försök att uppskatta den stressiga resan och fira framgången. Nu ska jag ta en öl och fira migreringen av den här datan från mitt huvud till papper.
- DevOps
- Eficode ROOT
Subscribe to our newsletter
Related blogs
