Att införa ett arbetsflöde för CI/CD inom applikationsutveckling blir allt vanligare. Samtidigt medför det utmaningar att skala upp och optimera CI/CD-processen.
Låt oss idag utforska vad dessa svårigheter innebär och hur man kan effektivisera och anpassa CI/CD-arbetsflöden. Häng med!
I dagsläget utvecklas appar ofta av team med flera programmerare. Varje individ eller teammedlem bidrar till projektet genom att fokusera på sin specifika del.
När projektet närmar sig slutet, står vi inför utmaningen att sammanfoga många olika kodavsnitt. Beroende på hur var och en har arbetat kan integreringen av dessa koder dra ut på tiden.
CI/CD, vilket står för kontinuerlig integration och kontinuerlig leverans/distribution, är en lösning på detta problem som säkerställer att uppdateringar kan publiceras utan onödiga dröjsmål eller konflikter. Låt oss titta närmare på denna process.
Kontinuerlig integration
Kontinuerlig integration, eller CI, omfattar metoder som strävar efter att regelbundet integrera kodförändringar och tillägg i en gemensam gren av projektet. Detta möjliggör testning av koden och att förbättringar och ändringar kan implementeras i realtid. Målet är att kontrollera varje element genom att skapa tester.
Denna kontinuerliga process motverkar att allt måste kontrolleras i ett enda steg i slutet av utvecklingen, och att man undviker att arbeta med alltför många element samtidigt. Därför är det mycket fördelaktigt att genomföra enhetstester för att säkerställa en hög kvalitet. Det gör det lättare att hitta fel tidigt genom att se till att koden kompileras korrekt och att regressioner undviks.
Kontinuerlig leverans
Kontinuerlig leverans, eller CD, sammanför kontinuerlig integration och testning som sedan kan paketeras i containrar och sättas i produktion. Det betyder att den samlar koder och genomförda tester och skickar dem till produktion via automatisering.
Även om manuella åtgärder kan krävas, blir det automatiserat genom att allt som har gjorts ”skickas ut” på ett integrerat och fullständigt sätt. I praktiken innebär det att med kontinuerlig leverans är vår applikation utvecklad så att den kan gå i produktion när som helst.
Kontinuerlig distribution
Även om koncepten kontinuerlig leverans och kontinuerlig distribution liknar varandra, finns det skillnader. Målet är detsamma, nämligen att applikationen ska användas i produktion, men medlen för att nå dit skiljer sig. Det som skiljer kontinuerlig leverans från kontinuerlig distribution är själva lanseringen.
Kontinuerlig distribution möjliggör direkt distribution av varje modifiering som passerar de olika stegen i vår pipeline. Under kontinuerlig leverans krävs ett manuellt godkännandesteg innan implementeringen kan ske.
Skalning av CI/CD
När antalet mikrotjänster växer är det nästan oundvikligt att man behöver skala sin CI/CD-pipeline. Ett ökat antal mikrotjänster leder till flera pipelines som är kopplade till ett enda git-arkiv, vilket i sin tur ökar belastningen på CI-servern och försämrar prestandan.
För att effektivt skala CI/CD behöver man skapa en standardiserad och automatiserad utvecklingspipeline som kan användas av alla team, vilket säkerställer kvaliteten på både individuella utvecklarleveranser och teamleveranser. Detta förenklar även hanteringen av pipelinen.
Skalning kan uppnås genom att definiera en CI-process för enhetstester och validering av koden, följt av en CD-process för att bygga och distribuera bilder i olika miljöer, samt att definiera en process för att bygga och distribuera bilder i produktionsmiljön.
Steg för att skala CI/CD
Det första steget är att anpassa pipelinen till arkitekturen och involvera teamledare. Detta inkluderar att kartlägga Git-grenar till miljöer (t.ex. develop -> development och master -> [homologation och produktion]). Därefter sker utlösningen av CI-jobb vid varje Pull Request och CD-jobb vid varje ändring i de kartlagda grenarna.
En jobbström kan skapas för att både CI och CD ska följas.
CI Job Flow utvecklas i sju steg:
- Kontrollera Pull Request käll- och destinationsgren;
- Kontrollera om sammanslagningen har konflikter som behöver lösas manuellt;
- Kör enhetstester;
- Bygg paketet för att verifiera integriteten och att koden är kompilerbar;
- Validera kodkvaliteten;
- Öka och commit projektversionen till källgrenen;
- Meddela Pull Request Git repository om resultatet via Webhook eller Rest API-anrop (Git Repository).
CD-jobbflödet följer denna väg:
- Den aktuella grenen checkas ut.
- Artefakten byggs med hjälp av det specifika byggverktyget som används i projektet.
- Efter att artefakten är byggd skickas projektets bibliotek 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 läggs till Docker-bilden.
Steg 2: Bilden laddas upp till Docker-registret.
Steg 3: Implementering sker genom utrullning av bilder via Kubernetes.
För applikationsprojekt i godkännande-/produktionsmiljöer, följ steg 1 och 2 ovan och sedan följande:
- Distribuera genom utrullning av bilder via Kubernetes i godkännandemiljön;
- Jobbet pausar för att vänta på godkännande för produktion;
- Om godkänt, marknadsför bilden för produktion;
- Annars rullas bilden tillbaka i godkännandemiljön.
CI/CD-optimering
CI/CD förbättrar applikationsutvecklingscykeln och löser problemen som uppstår vid integrering av ny kod, samtidigt som leveransfrekvensen ökar.
Här är några sätt du kan optimera din CI/CD-användning ytterligare:
Prioritera att reparera felaktiga byggen
När ett bygge går sönder bör det vara teamets högsta prioritet att åtgärda det. Om byggfelet inte kan åtgärdas inom några minuter, måste teamet besluta om de ska ta bort den berörda koden eller inaktivera den aktuella funktionsflaggan.
Tanken bakom att prioritera att reparera trasiga byggen är att säkerställa att varje bygge alltid genererar fungerande kod som kan publiceras.
Korta och täta driftsättningar
Programmets stabilitet kan riskeras vid varje driftsättning. Därför har man en tendens att distansera driftsättningarna från varandra. Problemet med det här är att för många ändringar samlas på hög. Om en av dessa förändringar orsakar ett fel, kan det tvinga oss att rulla tillbaka alla andra ändringar också, även om de fungerade.
Dela upp komplicerade ändringar till små, hanterbara enheter. Genom att distribuera oftare i små partier minskar risken för fel vid driftsättning.
Automatisera kvalitetssäkringstester för att minska risk
Vi har nog alla varit med om situationen ”det fungerade på min lokala maskin”, eftersom lokala utvecklingsmiljöer ofta skiljer sig åt. Det kan finnas skillnader mellan din lokala miljö och den produktionsmiljö där din app ska köras. Genom att automatisera kvalitetssäkringsuppgifter (QA), som till exempel webbläsartestning, kan du optimera din CI/CD och minska risken för att fel når den live-applikationen.
Förlita dig på automatiserade tester
För att validera koden som en utvecklare integrerar, använder CI en automatiserad och tillförlitlig testsvit. Om kod ska kompileras, är det första testet att verifiera att den kompileras. Därefter kan du lägga till så många tester som du anser vara kritiska.
Hur många tester ska inkluderas? CI:s mål är att ge feedback så snabbt som möjligt. Om en utvecklare måste vänta en timme på feedback fungerar det inte. Du kommer alltid att missa något, men när du upptäcker en bugg i produktion, skapa ett testfall och inkludera det i CI-loopen.
Tänk alltid på säkerheten
Tänk på säkerheten i CI/CD-verktyg, eftersom det integreras i befintliga konfigurationer eller miljöer. CI/CD kräver att alla säkerhetsverktyg anropas via programmering och att deras resultat samlas på ett och samma ställe. Leta efter verktyg som har API:er för automatisk krypteringsrevision.
Fördelar med skalning och optimering av CI/CD
Utöver att effektivisera utvecklingsteamen finns det andra fördelar med att skala och optimera CI/CD. Några av dem är:
Minskad overhead
Utvecklingstimmar är i regel faktureringsbara, men hur är det med tiden som läggs på manuell driftsättning av kod eller filer? Genom att automatisera stora delar av flödet sparar du tid som kan läggas på faktureringsbart arbete. Automatiserad testning gör också att fel upptäcks tidigare i processen i stället för i kvalitetssäkringen, i produktion eller, ännu värre, av kunden. Fler fel korrigerade på samma tid är en vinst.
Leverans med färre fel och mindre risk
Du upptäcker fel mycket tidigare i utvecklingsprocessen genom att publicera små ändringar oftare. När du implementerar automatiserade tester i alla utvecklingssteg minskar risken att skicka felaktig kod till nästa steg, och det är enklare att rulla tillbaka mindre ändringar vid behov.
Snabbare respons på förändringar i marknaden
Marknadsvillkoren förändras ständigt. Om en produkt plötsligt tappar intäkter eller att fler kunder besöker din webbplats från smartphones än från datorer, är det lättare att genomföra snabba förändringar 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 lansera felaktig kod avsevärt. Genom att vara transparent med processen och utbilda teammedlemmar och kunder ökar även deras förtroende för er som utvecklingsteam.
Slutsats
CI/CD påskyndar integrationer och leveranser. Det är dock viktigt att skala och optimera den för att undvika att processen blir kontraproduktiv på grund av ökad komplexitet.
Du kan även kika på några av de bästa CI-verktygen.