Har du hört talas om CI/CD men känner dig osäker på vad det egentligen innebär?
Mjukvaruutvecklare anlitas i huvudsak för att skapa kod som sedan ska distribueras till en produktionsmiljö. Detta görs för att verksamheten som efterfrågar produkten ska kunna använda den. För att möta verksamhetens (ofta kallade användare/kunder) behov är det avgörande att produkterna är fria från fel.
Den typiska arbetsmetoden för mjukvaruutvecklare är att jobba i olika grenar och sedan skapa en ”pull request” för att uppdatera huvudgrenen med de nya förändringarna. Det är vanligt att skriva tester för att säkerställa att de nya ändringarna inte introducerar några buggar. Ofta väntar utvecklarna med att skapa en ”pull request” tills de är helt klara med en funktion. När det väl är dags kan det leda till följande:
- De spenderar mycket tid på att försöka uppdatera sin lokala kodbas med de förändringar som har gjorts i produktionsgrenen under tiden de arbetat.
- De tvingas åtgärda en mängd sammanflätningskonflikter.
- Det finns också en risk att de oavsiktligt bryter produktionsgrenen, vilket i sin tur påverkar alla som hämtar kod från grenen innan felet upptäcks och åtgärdas.
Om du har varit i denna situation tidigare, vet du att det kan vara frustrerande. Ingen vill gärna spendera sin arbetsdag på detta vis.
Vad är då lösningen på detta?
Kontinuerlig Integration
För att undvika problemen som beskrivits ovan kan utvecklingsteam tillämpa metoden som kallas kontinuerlig integration. Denna metod innebär, som namnet antyder, att kodändringar som utvecklare gör fortlöpande integreras i en delad gren eller lagringsplats. Innan koden integreras måste den genomgå ett verifierat test för att säkerställa att den inte skadar applikationen. Integration sker först efter att testet godkänts.
Låt oss illustrera detta med ett praktiskt exempel. Anta att vi har ett team på tio utvecklare. Varje utvecklare skapar en lokal gren där de skriver kod för olika funktioner. Istället för att vänta med att skicka en ”pull request” tills de är helt klara med en funktion, väljer de att skicka ”pull requests” kontinuerligt, i takt med att de gör mindre ändringar. Ett exempel på en sådan ändring kan vara skapandet av en ny modal. Förutsatt att utvecklaren arbetar med en funktion som låter användaren hantera individuella uppgifter i applikationen, kommer denna lilla förändring att drivas ut och generera en ”pull request”. Detta istället för att vänta tills hela uppgiftsfunktionen är färdig, i linje med ett mönster för kontinuerlig integration.
Innan denna nya förändring integreras måste en rad automatiska tester köras.
Mjukvaruteam använder ofta verktyg som Travis CI för att automatisera dessa integrationsprocesser och tester. Med hjälp av dessa verktyg automatiseras testerna så att de körs så fort en ”pull request” skickas till den målgren som valts under installationen.
Resultaten av testerna genereras och utvecklaren som skapat ”pull requesten” kan se resultaten och göra nödvändiga ändringar. Fördelarna med att integrera kod i små bitar och att ha verifierade tester är:
- Det blir enkelt för teamet att identifiera vad som orsakat att byggprocessen eller testet misslyckats. Detta minskar risken för att skicka en bugg till produktion.
- Genom att automatisera processen får teamet mer tid att fokusera på produktivt arbete.
Det viktigaste att notera är att detta arbetssätt uppmuntrar teamet att regelbundet skicka kod till huvudgrenen. För att detta ska vara effektivt måste teammedlemmarna regelbundet uppdatera sin lokala kodbas genom att hämta senaste versionerna från huvudgrenen.
Typer av Tester
När du skriver tester som en del av integrationsprocessen, kan följande typer vara relevanta att inkludera:
- Integrationstester – kombinerar individuella mjukvaruenheter och testar dem som en helhet.
- Enhetstester – testar enskilda enheter eller komponenter, exempelvis metoder eller funktioner.
- UI-tester – verifierar att programvaran fungerar korrekt ur användarens perspektiv.
- Acceptanstester – kontrollerar att programvaran uppfyller de specificerade affärskraven.
Det är viktigt att komma ihåg att du inte behöver testa allt, då en del av testerna redan kan vara täckta i den kod som utvecklaren har skrivit.
Verktyg för Kontinuerlig Integration
Utan att gå in på detaljer, följer här några verktyg som du kan börja använda i dina nuvarande eller nya projekt:
- Travis CI – är ett välkänt verktyg i öppen källkodsvärlden som möjliggör sömlös testning av din kod på några minuter.
- Circle CI – ger dig kraft, flexibilitet och kontroll för att automatisera din pipeline från kodhantering till implementering.
- Jenkins – tillhandahåller hundratals plugins för att stödja byggande, driftsättning och automatisering av alla typer av projekt.
Om du är nybörjare på Jenkins kan det vara bra att kolla in den här Udemy-kursen om hur man lär sig CI med Java och .NET.
Kontinuerlig Leverans
Vilken nytta gör en ny funktion om den ligger och väntar i lagringsplatsen i flera veckor eller månader innan den distribueras till produktionsmiljön? Utöver att kontinuerligt integrera små förändringar i huvudgrenen, kan teamen också arbeta för att snabbt distribuera dessa ändringar till produktionsmiljön.
Målet med kontinuerlig leverans är att få ut ändringarna till användarna så fort utvecklarna har integrerat dem i huvudgrenen.
Precis som med kontinuerlig integration används automatiska tester och kontroller för att verifiera nyligen integrerade ändringar. Implementering sker endast när dessa tester har godkänts.
För att kunna dra nytta av kontinuerlig leverans behöver teamet ha följande på plats:
- Automatiserad testning är avgörande för all form av kontinuerlig utveckling. Koden som ska distribueras måste uppfylla de standarder som teamet har definierat för vad som ska skickas ut till slutanvändarna. Om en ny ändring inte uppfyller kraven ska testet misslyckas och inte implementeras.
- Även med automatiserade tester är det möjligt att vissa buggar kan slinka in i produktionsmiljön. Därför är det nödvändigt att teamet kan ångra gjorda ändringar, det vill säga återställa en implementering. Detta bör återställa produktionskoden till hur den var innan den nya ändringen gjordes.
- Övervakningssystem är viktiga för att följa de förändringar som har gjorts i produktionsmiljön. Detta gör att teamet kan spåra eventuella fel som användare stöter på när de använder de nya implementerade ändringarna.
De verktyg som nämnts för kontinuerlig integration ger dig också funktionalitet för att sätta upp ett system för kontinuerlig leverans. Det finns även många andra verktyg att läsa om.
Sammanfattning
Ett utvecklingsteams produktivitet är avgörande för företagets framgång. För att säkerställa produktivitet behöver metoder som uppmuntrar detta att implementeras. Kontinuerlig integration och kontinuerlig leverans är exempel på sådana metoder.
Kontinuerlig integration möjliggör för team att pusha ut så mycket kod som möjligt dagligen. När detta fungerar effektivt, blir det enkelt att distribuera de nya ändringarna till användarna så fort som möjligt. Genom att implementera ändringarna snabbt kan man få feedback från användarna, vilket i slutändan hjälper verksamheten att förnya sig baserat på den feedbacken. En win-win situation för alla.
Du kan också lära dig mer om hur man skalar och optimerar CI/CD.
Om du är utvecklare och intresserad av att lära dig mer om CI/CD, kolla in den här utmärkta kursen.
Tyckte du om att läsa den här artikeln? Dela den gärna med andra!