Att implementera ett CI/CD-arbetsflöde för applikationsutveckling blir allt mer populärt. Samtidigt är det dock en utmaning att skala och optimera CI/CD.
Idag ska vi diskutera vad denna utmaning är och utforska exakt hur vi kan skala och optimera CI/CD. Så följ med!
Numera sker applikationsutveckling vanligtvis i team bestående av flera utvecklare. Varje person eller team har sin roll i projektet genom att avancera på sin dedikerade del.
Vi befinner oss sedan i slutet av projektet med flera kodbitar att kompilera. Beroende på allas arbetssätt kan mycket tid gå till spillo på att hantera denna integration.
CI/CD, kontinuerlig integration och kontinuerlig leverans/distribution är en lösning på detta problem och säkerställer att uppdateringar släpps utan onödiga förseningar och konflikter. Låt oss förstå denna process.
Innehållsförteckning
Fortsatt integration
CI eller Continuous Integration grupperar processer som syftar till att kontinuerligt publicera kodändringar och tillägg till en delad gren av projektet. Det gör att koden kan testas och förbättringar och ändringar kan göras i realtid. Målet är att testa varje element genom att skapa tester.
Denna permanenta åtgärd gör det möjligt att inte kontrollera allt i ett block i slutet och att undvika att arbeta med för många element samtidigt. Att utföra enhetstester är därför mycket användbart för att säkerställa detta. Det är alltså lättare att upptäcka fel genom att se till att koden kompileras väl och inte skapar regressioner.
Kontinuerlig leverans
Kontinuerlig leverans eller CD sammanför kontinuerlig integration och testning som kan paketeras i behållare och sättas i produktion. Det vill säga att den samlar dessa koder och utförda tester och sätter dem i produktion via automatisering.
Även om det kräver mänskligt agerande, blir det automatiserat genom att allt som har gjorts ”sänds i luften” på ett integrerat och komplett sätt. Konkret, med den kontinuerliga distributionen är vår applikation utvecklad så att den kan sättas i produktion, oavsett när.
Kontinuerlig distribution
Även om koncepten kontinuerlig leverans och kontinuerlig distribution är likartade, finns det skillnader. Om deras mål är detsamma, det vill säga användningen av applikationen i produktionen, skiljer sig medlen för att uppnå det. Det som skiljer kontinuerlig leverans från kontinuerlig distribution är releasen.
Faktum är att kontinuerlig distribution gör det möjligt att direkt distribuera varje modifiering som korsar de olika stadierna av vår pipeline. Under kontinuerlig leverans är ett mänskligt valideringssteg nödvändigt för att implementeringen ska kunna ske.
Skalning CI/CD
När antalet mikrotjänster ökar blir det nästan oundvikligt att skala din CI/CD. Det ökade antalet mikrotjänster resulterar i olika pipelines anslutna till ett enda git-förråd vilket ökar belastningen på CI-servern och sänker prestandan.
För att skala CI/CD är det nödvändigt att skapa en standardiserad och automatiserad utvecklingspipeline för alla team och därifrån säkerställa kvaliteten på individuella utvecklarleveranser och teamleveranser. Det gör också hanteringen av pipelinen enkel.
Skalning kan åstadkommas genom att definiera en CI-process för att utföra enhetstester och validera kvaliteten på den levererade koden.
Följt av en CD-process för att bygga bilderna och distribuera dem i miljöerna kontinuerligt och slutligen definiera en process för att bygga bilderna och distribuera dem i produktionsmiljön.
Steg för att skala CI/CD
Det första steget är att anpassa pipelinen till arkitekterna och involvera teamledare. Den följer kartläggningen av Git-grenarna till miljöerna (develop -> development and master -> [homologation and production]). Det kommer sedan avfyrandet av CI-jobbet vid varje Pull-begäran och CD-jobbet vid varje ändring i de mappade grenarna.
En jobbström kan skapas för att både CI och CD ska följas.
CI Job Flow utvecklas i 7 steg:
- Kolla in Pull Request-källan och destinationsgrenen;
- Kontrollerar om sammanslagningen inte har konflikter som behöver lösas manuellt;
- Kör enhetstester;
- Bygg paketet för att verifiera integriteten och att koden är kompilerbar;
- Validering av triggkodkvalitet;
- Öka och commit projektversionen till källgrenen;
- Meddela Pull Request Git repository om framgång eller misslyckande via Webhook eller Rest API-anrop (Git Repository).
CD-jobbflödet följer följande väg:
- Den anmälda filialen är utcheckad.
- Artefakten byggs med hjälp av det specifika byggverktyget för projektet som arbetas med.
- Efter att artefakten kommer skickas biblioteksprojekten till Nexus för lagring av artefakten och flödet avslutas.
Följande åtgärder utförs:
Steg 1: En Docker-bild skapas för den genererade artefakten, och artefaktversionen appliceras på Docker-bilden.
Steg 2: Bilden laddas upp till Docker-registret.
Steg 3: Implementering genom utrullning av bilder via Kubernetes.
För applikationsprojekt som befinner sig i en godkännande-/produktionsmiljö, följ steg 1 och 2 ovan och sedan följande:
- Distribuera genom bildutrullning via Kubernetes i godkännandemiljön;
- Jobbet tar en paus för att vänta på att utbyggnaden ska godkännas för produktion;
- Om den godkänns marknadsförs bilden som godkänns för produktion;
- Annars rullar den tillbaka bilden i godkännande.
CI/CD-optimering
CI/CD förbättrar applikationsutvecklingscykeln och löser problemet som orsakas av att integrera ny kod och öka leveransfrekvensen.
Följande är hur du kan optimera användningen av CI/CD ytterligare:
Prioritera att fixa en skadad version
När ett bygge går sönder bör det vara lagets prioritet att fixa det. Om konstruktionen inte kan fixas på några minuter måste teamet bestämma om de ska ta bort koden eller inaktivera funktionsflaggan.
Tanken bakom att fixa ett trasigt bygge är att bygget alltid kommer att producera fungerande kod som kan släppas.
Små täta utplaceringar
Generellt sett är programmets stabilitet i fara närhelst en distribution sker. Så vi tenderar att distansera utplaceringar från varandra. Problemet med detta tillvägagångssätt är att vi samlar på oss för många förändringar. En av dessa förändringar kan gå fel och tvinga oss att dra tillbaka de andra som fungerade.
Applicera strypmönstret och bryt komplicerade förändringar till små och enkla. Om du distribuerar oftare och arbetar i små partier är risken för driftsättning lägre.
Automatisera QA-tester för riskreducering
Vi har förmodligen alla varit inblandade i scenariot ”arbetade på min lokala maskin” eftersom lokala utvecklingsmiljöer ofta skiljer sig åt. Det kan vara många olika saker mellan din närmiljö och var du går in i produktionen. Du kan optimera CI/CD genom att automatisera kvalitetssäkringsuppgifter (QA) såsom webbläsartestning, vilket minskar risken för att ett fel når live-applikationen.
Lita på automatiserade tester
För att validera när en utvecklare integrerar ny kod, förlitar sig CI på en automatiserad och pålitlig testsvit. Om du behöver kompilera kod är det första testet att den kompilerar. Sedan kan du lägga till så många tester som du anser vara kritiska.
Hur många tester ska inkluderas? För att fastställa detta, kom ihåg att CI:s mål är att ge feedback så snabbt som möjligt. Om en utvecklare måste vänta en timme för att få feedback kommer det inte att fungera. Du kommer alltid att missa saker, men när du upptäcker en bugg i produktionen, skapa ett testfall och inkludera det i CI-loopen.
Tänk alltid på säkerheten
Tänk på säkerheten hos ett CI/CD-verktyg eftersom det integreras i befintliga konfigurationer eller miljöer. CI/CD kräver att alla säkerhetstestverktyg anropas programmatiskt och deras resultat samlas på ett ställe. Leta efter verktyg som har API:er för automatisk krypteringsrevision.
Fördelar med skalning och optimering av CI/CD
Förutom att öka effektiviteten hos utvecklingsteam har skalning och optimering av CI/CD också andra fördelar, av vilka några är:
Minskad overhead
Utvecklingstimmar är vanligtvis fakturerbara, men hur är det med tiden som ägnas åt att manuellt distribuera kod eller filer? Att automatisera stora delar av ditt flöde sparar tid för fakturerbart arbete, något som alla kan uppskatta. Automatiserad testning låter dig också misslyckas tidigare snarare än att hitta fel i QA eller produktion eller ännu värre, kunden hittar dem. Fler buggar fixade på samma tid är en klar vinst.
Leverans med färre buggar och mindre risk
Du fångar buggar mycket tidigare i utvecklingsprocessen genom att släppa mindre ändringar oftare. När du implementerar automatiserade tester i alla utvecklingsstadier riskerar du inte att flytta den felaktiga koden till nästa steg, och det är lättare att återställa mindre ändringar vid behov.
Reagera snabbare på marknadsförhållandena
Marknadsförhållandena förändras ständigt. Anta att du upptäcker att en ny produkt tappar intäkter eller att fler kunder kommer åt din webbplats från smartphones än bärbara datorer. I så fall är det mycket lättare att göra en snabb förändring om du har optimerat kontinuerlig leverans.
Förtroende
Om du har optimerat CI/CD, vilket innebär att du har en robust testsvit, ökar ditt förtroende för att inte skicka in en bugg avsevärt. Om du är transparent med din process och utbildar resten av ditt team och kunder ökar även deras förtroende för dig som utvecklingsteam.
Slutord
CI/CD gör dina integrationer och leveranser snabbare. Det är dock viktigt att skala och optimera den för att undvika att processen blir kontraproduktiv på grund av ökande komplexitet.
Du kan också titta på några av de bästa CI-verktygen.