CI/CD står för Continuous Integration and Continuous Delivery. Men vad betyder det ens och varför skulle du vilja ha det i din Android-app (eller någon annan)?
Jag föredrar att se det som två separata saker, som kompletterar varandra men också är oberoende av varandra.
Ur ett ingenjörsperspektiv avses vanligtvis med CI/CD bara CI-delen. Det är en process för att automatisera integrationen av nya kodändringar i kodbasen. Detta innebär att validera ny kod när den anländer, vanligtvis via Pull Requests. En framgångsrik CI hjälper till med:
Dessutom kan det förhindra att overifierad kod slås samman med huvudkodbasen. Och det gör det på ett automatiserat och transparent sätt. Genom att ha en sådan konfiguration behöver kodgranskare inte avbryta sitt arbetsflöde genom att checka ut en ny gren bara för att utföra manuella kontroller som att köra tester och kodanalys. På så sätt är huvudkodbasen alltid släppbar, vilket leder oss till den andra delen av CI/CD — Continuous Delivery.
I produktsammanhang finns det som kallas CI/CD i själva CD:n – en metod för att automatisera appleverans till kunder. Vanligtvis förutsätter detta distribution av nya appversioner till dina kunder på ett automatiserat och kontinuerligt sätt. Kontinuerlig leverans som konfigureras i ditt projekt har många fördelar, såsom:
De flesta projekt och startups jag har arbetat med börjar med Continous Delivery. Det gör det möjligt för kunder och tidiga användare att aktivt inkluderas i mjukvaruutvecklingens livscykel, helt enkelt genom att ha den senaste appversionen nära till hands innan den släpps till en bredare publik. Vissa kommer att anse det som en impopulär åsikt, men jag tror att detta sätt att engagera sig och transparens ger mer värde än Continuous Integration i projektens tidiga dagar. CI ses ofta som en förhastad optimering, särskilt i detta skede och i mindre team.
Andra projekt jag har arbetat med har inte ens ett UI eller konkreta resultat. Det här är SDK:er (bibliotek) som andra utvecklare kan inkludera i sina appar. I dessa miljöer är CI mer fördelaktigt än CD. Det kanske inte finns någon app att lansera, men biblioteksartefakterna måste fortfarande publiceras någonstans, som på Maven Central Repository – därför ska CD inte ignoreras.
Även om CI och CD är separata processer, kallas de ofta tillsammans för en CI/CD-pipeline . En pipeline är en serie olika steg som måste utföras för att integrera och leverera en ny version av en app.
Ingenjörer använder ofta CI/CD-leverantörer för att bygga och driva en pipeline. De mest kända leverantörerna inkluderar:
Dessa leverantörer hjälper till att automatisera testning, validering och distribution och tar hand om infrastruktur, nätverk och säkerhet. Ingenjörer skriver en CI/CD-pipeline, vanligtvis i form av en YAML-konfigurationsfil, där de beskriver exakt hur tester ska köras, hur appen ska signeras och hur man skickar ett Slack-meddelande när bygget lyckas.
Utgångspunkten och den mest grundläggande punkten för alla CI/CD-installationer är dess integration med ett versionshanteringssystem där källkoden finns, såsom GitHub, Bitbucket eller GitLab. I praktiken måste en CI/CD-leverantör som Codemagic eller Bitrise ha tillgång till kodförrådet för att kunna checka ut och bygga appen från det, dvs. köra pipelinen mot kodbasen.
I andra änden utlöser GitHub (eller någon annan leverantör) CI/CD-leverantörens webbkrok när ny kod skickas eller en Pull-förfrågan öppnas. Detta innebär att versionskontrollsystemet anropar en HTTP-slutpunkt och även skickar en JSON-nyttolast, som innehåller metadata såsom information om commit-författaren, påverkad git-gren, antal ändrade filer etc. CI/CD-leverantören konsumerar den nyttolasten och bestämmer om den ska köra pipelinen eller inte. Pipelinen kan till exempel konfigureras att köras när en Pull-förfrågan slås samman med bemästra endast gren, vilket gör att CI/CD-leverantören ignorerar ändringar i andra grenar.
En bra CI/CD-leverantör gör webhook-kablarna när de först integreras i ett VCS-system. För det mesta sker all kommunikation bakom kulisserna och kräver inte ingenjörernas uppmärksamhet.
Kort sagt, alla CI/CD-leverantörer ger dig en virtuell maskin i molnet, som analyserar YAML-filen och kör kommandon som definieras i den. Detta ger stor flexibilitet – du får tillgång till någon annans dator i molnet, fri att göra vad du vill med den. Precis som du skulle göra med din alldeles egna dator.
Vissa CI/CD-leverantörer tillåter till och med fjärråtkomst till byggmaskinen, via SSH- eller VNC-klienter. Även om detta absolut inte behövs i vanlig CI/CD, kan det vara praktiskt i felsöknings- och felsökningsfaser.
I motsats till namnet behöver det inte vara kontinuerligt att bygga CI/CD-pipelinen, och det är det vanligtvis inte heller – det är inte alls en vardaglig uppgift. Ingenjörer väljer en CI/CD-leverantör utifrån sina behov. De bygger en pipeline och skräddarsyr den efter sina behov bara en gång. I praktiken handlar det om att skapa en YAML-konfigurationsfil som beskriver vad CI/CD-leverantören ska göra. De flesta vanliga inställningar innehåller definitioner av hur fjärrmaskinen ska checka ut koden, bygga appen, köra tester och distribuera den till en bredare publik. Den YAML-konfigurationsfilen finns i Git-arkivet tillsammans med kodbasen.
Med en välgjord YAML-fil på plats finns det egentligen inte mycket kvar där. Enhetstester körs när Pull Requests anländer, och byggen signeras och driftsätts när kod slås samman till en specifik git-gren – om den är konfigurerad för det. CI/CD-pipelinen fungerar under huven, lyssnar efter hooks som utlöser den, och kräver för det mesta ingen direkt uppmärksamhet.
Precis som JSON eller XML, som du förmodligen är mer bekant med som mobilutvecklare, är YAML Yet Another Markup Language – därav dess ursprungliga namn. Ja, det är ytterligare ett dataserialiseringsspråk att förstå, men den goda nyheten är att allt som kan skrivas i XML eller JSON enkelt kan uttryckas i YAML också.
YAML används flitigt för att skriva konfigurationsfiler inom DevOps-världen. Det är mindre utförligt än XML och mer läsbart än JSON, samtidigt som det fortfarande låter utvecklare exakt beskriva vad de vill ha.
Viktigast av allt är att YAML är läsbart och lätt att både läsa och skriva. Så här ser en typisk YAML-fil ut:
Denna YAML-fil är specifikt skriven för att användas med Codemagic , en utmärkt och intuitiv CI/CD-lösning för mobilappar. Enkelt uttryckt instruerar denna konfigurationsfil Codemagic att:
bemästra gren.#allmän Slack-kanal.Olika CI/CD-leverantörer har olika så kallade YAML- scheman . Ett bra YAML- schema är självförklarande, precis som det ovan.
Varje CI/CD-leverantör har ett unikt schema som definierar vad du kan göra och hur du gör det med deras YAML-filer. Ett YAML-schema är dock inte detsamma som YAML-syntaxen, som i sig alltid är konstant eftersom det alltid är samma språk – YAML. I exemplet ovan, instanstyp: mac_mini är hur du uttrycker vilken maskin du vill att pipelinen ska köras på. Motsvarande avsikt i t.ex. Github-åtgärder är körs-på: macos-senaste.
Som tur är behöver du inte komma ihåg scheman eller memorera olika YAML-fuskblad för din valda CI/CD-leverantör. De flesta moderna IDE:er validerar inte bara YAML-syntaxen utan även schemat:
Vissa CI/CD-leverantörer stöder inte YAML-konfiguration alls. Istället tillhandahåller de ett webbgränssnitt som vanligtvis är mindre funktionsrikt men sparar tid och resurser genom att kickstarta din pipeline, som den här från Microsofts App Center :
Det finns många alternativ där ute när du ska välja rätt CI/CD-leverantör. Var och en är unik med sina distinkta funktioner.
Här är några viktiga kriterier att beakta:
Det finns otaliga CI/CD-leverantörer där ute, såväl som otaliga artiklar om CI/CD. Ur ett genomsnittligt ingenjörsperspektiv gör de ingen skillnad i sig, förrän du når ditt alldeles egna aha-ögonblick .
Programvaruutvecklare har svårare att förstå koncept som inte nödvändigtvis är en del av den dagliga utvecklingen. Till exempel insåg jag inte vikten av att skriva enhetstester förrän projektets kodbas hade vuxit till en grad där det var oundvikligt att introducera regressionsbuggar med alla andra funktioner.
Det tog utan tvekan tid för mig att förstå varför CI/CD också är viktigt. Att manuellt bygga och skicka APK-filer till klienter och QA kändes alltid fel för mig.
Ett annat personligt och verkligt exempel var en förfrågan från ett QA-team. De bad om en ny app-version från en specifik git-gren. Överraskande nog är det en lat söndagsmorgon och en lång deadline framför oss. Utan CI/CD-installation är dessa de vanliga stegen jag skulle ta:
Men eftersom vi hade CI/CD på plats då, räckte det med ett eller två tryck på AppCenters webbdashboard för att leverera en ny version – till och med utan att behöva gå upp ur sängen! Pipelinen tog hand om alla steg ovan, och mer därtill.
Lycka till med piping!