Kontinuerlig Integration/Kontinuerlig Utveckling

Inom mjukvaruutveckling är kontinuerlig integration den metod som används för att hålla huvudkällkoden (ofta kallad huvudgrenen) i ett stabilt tillstånd. Varför man skulle försöka uppnå detta mål är uppenbart. Icke-fungerande kod är inte särskilt användbar, och det kan vara ganska kostsamt att åtgärda den. Hur man undviker detta och skapar så optimal kod som möjligt har blivit en egen gren inom mjukvaruingenjörskonsten, och i många fall finns det ett helt team som arbetar med att uppnå detta mål. Nu kan detta mål naturligtvis uppnås på olika sätt, och ofta har utvecklingsteam sina egna arbetsmetoder. I den här artikeln kommer jag att ge dig en inblick i några möjliga sätt att gå tillväga.

Enligt min erfarenhet är en nödvändighet för att uppnå detta mål att praktisera kontinuerlig integration (CI). Det finns flera tekniker för hur man tillämpar CI, och den mest lämpliga metoden beror naturligtvis på den specifika kontext där CI används. Det finns dock vissa grundläggande principer som jag anser alltid bör tillämpas:

• Alla som arbetar med koden bör alltid ha den senaste kopian av huvudgrenen i sin utvecklingsmiljö så lättillgängligt som möjligt.

• Alla ändringar i huvudgrenen bör vara så minimala och atomiska som möjligt.

• Använd en pipeline för att säkerställa att huvudgrenen är så stabil som möjligt.

• Om huvudgrenen bryts måste det åtgärdas omedelbart, och det bör vara enkelt att återgå till en tidigare version av den.

En sak som jag tycker är viktig att klargöra här är vad en pipeline är och dess betydelse.

Pipelines

En högkvalitativ huvudgren är medlet och målet med CI, och enligt min åsikt är det mest effektiva och enklaste sättet att uppnå detta genom att använda pipelines. Men vad gör egentligen en CI-pipeline? Vanligtvis lyssnar den på ändringar i kodbasen (inte nödvändigtvis bara huvudgrenen) och triggar byggen. Den kör sedan olika kvalitetssäkringstester på kodbasen. Detta kan låta komplicerat, men den goda nyheten är att det finns ett stort antal verktyg tillgängliga idag för jobbet, såsom Jenkins, CircleCI och Github Actions, för att nämna några.

Det är helt upp till projektägaren när pipelinen ska triggas och vad den ska göra då. Men eftersom huvudsyftet med detta är att hålla huvudgrenen stabil, bör varje ändring i den gå genom pipelinen. Dessutom kan pipelinen konfigureras för olika andra saker också (se exempel under "Kontinuerlig distribution/kontinuerlig leverans"). Som en slutlig anmärkning kan betydelsen av en stark och pålitlig testsvit inte underskattas när man använder en pipeline. Enkelt uttryckt, dåliga tester = dålig pipeline.

Kontinuerlig distribution/kontinuerlig leverans

För att ta det ett steg längre, låt oss titta på kontinuerlig distribution/kontinuerlig leverans. Kontinuerlig distribution avser praktiken att automatiskt släppa mjukvaran när den klarar vissa tester. Eftersom vi nu är i området för att potentiellt bryta produktionen måste du vara något försiktig. Om vi låter en bugg smyga sig förbi vår testsvit kan det orsaka allvarliga problem. Därför är en robust testsvit absolut avgörande. Enligt min erfarenhet är det mer förnuftiga tillvägagångssättet att använda kontinuerlig leverans istället. Skillnaden mellan de två praktikerna är att med kontinuerlig leverans gör vi allt vi gör i kontinuerlig distribution, men vi behöver också mänskligt godkännande för alla releaser till produktion. Detta är en perfekt möjlighet att göra manuella tester eller användartester med en testgrupp för att säkerställa att det som finns i produktionen är av högsta kvalitet. Hur gör vi allt detta? Du gissade rätt, pipelines! Vi kan helt enkelt lägga till en ny pipeline eller omkonfigurera den nuvarande för att köra distributionsskript också. På samma sätt gör kontinuerlig leverans detsamma, men istället lyssnar den på mänskliga triggar för att börja köra.

Slutliga tankar

För att sammanfatta kommer jag att lämna dig med några slutliga tankar. Den första är att starkt uppmuntra läsaren att använda CI/CD så tidigt som möjligt i nästan varje projekt. Med de verktyg som finns tillgängliga är det enkelt att börja praktisera CI/CD, och den tid du sparar på ganska tröttsamt buggjagande och frustrerande felsökning är enligt min erfarenhet alltid värt det. För det andra, investera tid i en stark testsvit. Jag skulle rekommendera detta till varje läsare oavsett din användning av CI/CD. Slutligen, när du använder CI/CD, kommer avkastningen på din investering att bli kraftigt förstärkt, och du och alla som arbetar med projektet kan spendera mer tid på den mest givande delen av mjukvaruutveckling: att implementera coola och spännande funktioner!