Refaktorera pipelines för smidiga övergångar mellan verktyg

När projektet (och de pipelines som bygger och testar det) växer har vi ofta sett att team behöver lägga allt mer tid på att underhålla dem. Resultatet blir att CI/CD är det enda sättet att bygga och testa mjukvaran, eftersom den bara fungerar på en enda maskin.

Om dina CI/CD-verktyg slutar fungera kan det alltså få katastrofala följder för teamet, eftersom all utveckling stannar helt utan dem. Men även om det aldrig händer är det svårt, kanske till och med omöjligt, att migrera till nyare och mer avancerade verktyg. Och behöver vi verkligen förklara varför du alltid vill ha bättre verktyg?

I den här bloggen delar jag tips på hur du undviker problemet ”fungerar på min maskin” och kan dra nytta av nya CI/CD-verktyg framöver.

Containerisera varje steg

Kort sagt tvingar containerisering som koncept dig att tänka igenom indata och önskat resultat. Att tänka i containeriserade steg när du arbetar med CI/CD liknar hur du arbetar med programmeringsfunktioner.

Det finns flera fördelar med att containerisera varje steg på det här sättet:

1. Versionshantering blir enklare eftersom du får en historik över hur varje steg har utvecklats och kan använda flera versioner av samma sak i olika sammanhang, till exempel projekt.

2. Containerisering förenklar testning och felsökning, eftersom du enkelt kan köra containern på din utvecklingsmaskin när något går fel i pipelinen.

3. Docker, ett populärt verktyg för containerisering, uppmuntrar till att skapa lätta containrar, alltså steg, vilket ger mycket hög prestanda.

4. Om saker och ting är väl modulariserade kan vi också köra de olika stegen parallellt. Läs mer om Directed Acyclic Graph (DAG).

Den interna logiken i containrar kan vara komplex, vilket jag återkommer till senare, men logiken som interagerar med sådant utanför containern bör alltid hållas enkel – en princip du alltid bör följa.

Använd ett tredjepartsverktyg för att distribuera dem i organisationen

Ett repository med organisationens alla containeriserade CI/CD-steg gör dem enklare att hitta och återanvända. Det innebär att teamen slipper göra extra arbete när stegen redan finns på plats. Det förbättrar i sin tur samarbetet i hela organisationen.

Dessutom kan du, även om din CI/CD slutar fungera, med några docker pull-kommandon köra samma steg som i din CI/CD. Det innebär att arbetet aldrig behöver avbrytas.

Använd uppgiftsverktyg för att kapsla in komplex logik

Bash är bra, men det är ett 50 år gammalt programmeringsspråk som börjar visa sin ålder. Nu har vi nyare, modernare programmeringsspråk, som vi redan använder i våra projekt, för att uttrycka komplex logik. Och låt oss vara ärliga: alla påstår att de kan bash, men det kan de egentligen inte – jag själv inkluderad.

Om du därför behöver komplex logik, mer än enkel if-else-förgrening, i dina build pipelines kan du med de här verktygen skriva logiken på det programmeringsspråk som används i projektet och som du redan kan.

Varje språk har ett verktyg för uppgifter. Några välkända exempel är:

• NPM för Node

• Invoke för Python

• Rake för Ruby

• Maven för Java

• Bazel för C

Använd de här uppgiftsverktygen i dina containrar i stället för att skriva bash-skript. Då kan du använda andra beprövade metoder inom mjukvaruutveckling, till exempel enhetstestning, för att säkerställa att logiken fungerar i alla lägen – utan att behöva växla mellan ”riktig” kod och CI/CD-kod.

Secrets och miljövariabler utanför CI/CD

Hemligheter och miljövariabler växer i antal under ett projekts livslängd och ökar komplexiteten. Därför bör de delas in i två separata kategorier:

Vid build: Dessa behövs under CI/CD-processen för att paketera projektet till användbara artefakter. Du bör alltid försöka minimera dem, men du blir aldrig helt av med dem.

Vid körning: Dessa behövs när applikationen startar (eller medan den körs). Det finns ofta många av dem, och de läggs ofta in i CI/CD, men de fungerar bättre om de inte finns där från början. Till exempel bakar man ofta in autentiseringsuppgifter och URL:er för databasanslutningar i CI/CD. Men vad händer om du behöver ändra dem när programvaran är i drift? Om de finns i din CI/CD måste du skapa en ny release, vilket är mindre smidigt än att redigera dem i ett tredjepartssystem som HashiCorp Vault. Genom att ta bort dem ur ekvationen minskar du konsekvenserna om CI/CD ligger nere.

Avslutande tankar

Om du följer alla stegen jag har listat ovan är du på god väg mot snabbare CI/CD – och allt blir enklare. Det är förstås lättare sagt än gjort. Men förhoppningsvis känns de här stegen inte alltför skrämmande!