Förstå kontinuerlig integration och kontinuerlig implementering

Hört CI/CD men inte säker på vad det är?

Helst anlitas mjukvaruingenjörer för att skriva kod som måste skickas till en produktionsmiljö så att verksamheten som behöver produkten kan använda den. För att tillfredsställa verksamheten (ofta kallad användare/klienter) är det viktigt att produkterna är buggfria.

Det typiska tillvägagångssättet som mjukvaruingenjörer följer är att arbeta i grenar och skapa en pull-begäran som uppdaterar huvudgrenen med den nya uppdateringen som har gjorts. Vi har anammat praxis att skriva tester som ett sätt att säkerställa att de nya ändringarna inte introducerar buggar. När utvecklare arbetar med en funktion i de flesta fall skapar de ofta inte en pull-begäran förrän de är helt klara med funktionen. Vad som händer när de är redo är att;

  • De lägger ner mycket tid på att försöka uppdatera sin kodbas med de förändringar som har skett i produktionsgrenen medan de arbetade.
  • Genom att göra det måste de fixa en rad sammanslagningskonflikter.
  • Det finns också möjlighet att de bryter produktionsgrenen, vilket fortsätter att påverka de som drar sig från grenen innan problemet har setts och åtgärdats.

Om du någonsin har varit i den här situationen kommer du att hålla med om att det kan vara jobbigt – ingen vill gärna spendera sin arbetsdag så här.

Vad är lösningen?

Fortsatt integration

För att förhindra de scenarier jag nämnde ovan; ingenjörsteam kan använda den praxis som kallas kontinuerlig integration – som namnet antyder, innebär det kontinuerlig integrering av kodändringar som görs av utvecklare i den delade grenen/förrådet. Koden som ska integreras måste genomgå ett verifierat test för att säkerställa att den inte bryter applikationen. Det är först när testet går som det integreras

För att förstå detta, låt oss föreställa oss ett verkligt scenario där det finns ett team på 10 utvecklare. Dessa utvecklare skapar en filial lokalt där de skriver kod för implementering av vissa funktioner. Istället för att skicka pull-förfrågningar när de är helt klara med funktionen, väljer de att skicka pull-förfrågningar eftersom de gör små ändringar. Ett exempel på en sådan förändring kommer att vara skapandet av en ny modal, förutsatt att utvecklaren arbetar med en funktion som tillåter användare att hantera individuella uppgifter i applikationen. Istället för att vänta tills uppgiftsfunktionen är klar, för att följa ett kontinuerligt integrationsmönster, driver utvecklaren denna lilla förändring (jämfört med vad hon arbetar med) och skapar en pull-begäran för att slås samman med koden.

Innan denna nya förändring integreras måste en serie tester köras.

Programvaruteknikteam använder sig av verktyg som Travis CI att skapa dessa integrationsprocesser och tester. Med verktyg som dessa är testerna automatiserade, så att de körs så snart en pull-begäran skickas till den målgren som valts under installationen.

Resultaten av testerna genereras och utvecklaren som skapade pull-förfrågningarna kan se resultaten och göra nödvändiga ändringar. Fördelarna med att hålla fast vid detta mönster att integrera kod så lite som möjligt och ha ett verifierat test att köra är;

  • Det blir möjligt för det inblandade teamet att veta vad som gjorde att byggprocessen eller testet misslyckades. Detta minskar möjligheten att skicka en bugg till produktion.
  • Om teamet automatiserar processen kommer de att ha lyxen av tid att fokusera på att vara produktiva.

Det viktiga att notera i denna praxis är att det uppmuntrar teamet att ofta skicka kod till huvudgrenen. Att göra detta kommer att vara ineffektivt om andra medlemmar i teamet inte drar sig från huvudgrenen för att uppdatera sitt lokala arkiv.

Typer av tester

När du skriver tester som kommer att vara en del av integrationsprocessen, här är några som kan implementeras i processen:

  • Integration – den kombinerar individuella enheter av programvaran och testar dem som en grupp.
  • Enhet – den testar för enskilda enheter eller komponenter i programvaran som metoder eller funktioner.
  • UI – hävdar att programvaran fungerar bra ur användarens perspektiv.
  • Acceptans – testar att programvaran uppfyller affärskraven.

Det är viktigt att notera att du inte behöver testa alla dessa, eftersom en handfull av dem redan kan vara täckta i koden skriven av utvecklaren.

Verktyg för kontinuerliga integrationer

Utan att gå in på djupet finns här verktyg som du kan börja använda i dina nuvarande eller nya projekt;

  • Travis CI – känd i världen med öppen källkod och lovar dig att få din kod testad sömlöst på några minuter.
  • Cirkel CI – ger dig kraft, flexibilitet och kontroll för att automatisera din pipeline från kontroll till implementering.
  • Jenkins – tillhandahåller hundratals plugins för att stödja byggande, driftsättning och automatisering av alla projekt.

Om du är ny på Jenkins skulle jag föreslå att du tar detta Udemy kurs att lära sig CI med Java och .NET.

Kontinuerlig distribution

Vad bra kommer det att vara om funktionen du bygger sitter i förvaret i veckor eller månader innan den distribueras till produktionsmiljön. Så mycket som ingenjörsteam kan arbeta för att integrera små förändringar i huvudgrenen när det händer, kan de också driva dessa förändringar till produktionsmiljön så snart som möjligt.

Målet när man övar på kontinuerlig driftsättning är att få ändringarna gjorda ner till användarna så snart utvecklarna integrerar dessa förändringar i huvudgrenen.

Liksom i fallet med kontinuerlig integration, när man använder sig av kontinuerlig driftsättning, ställs automatiska tester och kontroller upp för att säkerställa att de nyligen integrerade ändringarna verifieras. Implementeringen sker bara när dessa tester är godkända.

För att ett team ska kunna dra nytta av övningen med kontinuerlig utplacering måste de ha följande på plats;

  • Automatiserad testning är den väsentliga ryggraden i all kontinuerlig teknisk praxis. I fallet med kontinuerlig distribution måste koden som ska distribueras uppfylla den standard som teamet har infört för vad de avser att skicka ut till slutanvändare. Om en ny ändring ligger under tröskeln bör testet helst misslyckas och inte integreras. Annars blir det integrerat.
  • Trots att de har automatiserade tester back-to-back, är det möjligt att vissa buggar kommer att glida in i produktionsmiljön. För detta är det nödvändigt att teamet kan ångra en förändring som har gjorts – ångra en implementering. Detta bör återställa produktionskoden till vad den var innan den nya ändringen gjordes.
  • Övervakningssystem behövs för att hålla reda på förändringar som har pressats till produktionsmiljön. Detta är hur teamet kan spåra buggar som användare stöter på när de använder de implementerade ändringarna.

De nämnda verktygen för kontinuerlig integrering ger dig också funktionaliteten för att sätta upp ett system för kontinuerlig driftsättning. Det finns massor av dem du också kan läsa om.

Slutsats

Produktiviteten hos ett utvecklingsteam är avgörande för företagets framgång. För att säkerställa att de är produktiva måste metoder som uppmuntrar detta antas. Kontinuerlig integration och implementering är exempel på sådana metoder.

Med kontinuerlig integration kan team trycka på så mycket kod som möjligt dagligen. Med detta uppnått blir det enkelt att distribuera de nyligen tillagda ändringarna till användaren så snart som möjligt. Att implementera dessa ändringar gör det möjligt att få feedback från användarna. I slutändan kommer verksamheten att kunna förnya baserat på den feedback som erhålls, vilket är en win-win för alla.

Du kan också lära dig hur du skalar upp och optimerar CI/CD.

Om du är en utvecklare och intresserad av att lära dig CI/CD, kolla in det här lysande kurs.

Gillade du att läsa artikeln? Vad sägs om att dela med världen?