Har du hørt CI/CD, men ikke sikker på hvad det er?
Ideelt set ansættes softwareingeniører til at skrive kode, der skal sendes til et produktionsmiljø, så den virksomhed, der har brug for produktet, kan gøre brug af det. For at tilfredsstille forretningen (ofte kaldet brugere/klienter) er det vigtigt, at produkterne er fejlfrie.
Den typiske tilgang, som softwareingeniører følger, er at arbejde i filialer og oprette en pull-anmodning, som opdaterer mastergrenen med den nye opdatering, der er blevet lavet. Vi har indført praksis med at skrive test som et middel til at sikre, at de nye ændringer ikke introducerer fejl. Når udviklere arbejder på en funktion i de fleste tilfælde, opretter de ofte ikke en pull-anmodning, før de er helt færdige med funktionen. Det der sker når de er klar er at;
- De bruger meget tid på at forsøge at bringe deres kodebase ajour med de ændringer, der er sket i produktionsgrenen, mens de arbejdede.
- Ved at gøre det skal de løse en række fusionskonflikter.
- Der er også mulighed for, at de bryder produktionsgrenen, hvilket fortsætter med at påvirke dem, der trækker sig fra grenen, før problemet er set og rettet.
Hvis du nogensinde har været i denne situation, er du enig i, at det kan være en smerte – ingen kan villigt lide at bruge deres arbejdsdag på denne måde.
Hvad er løsningen?
Indholdsfortegnelse
Kontinuerlig integration
For at forhindre de scenarier, jeg nævnte ovenfor; ingeniørteams kan anvende den praksis, der kaldes kontinuerlig integration – som navnet antyder, involverer det kontinuerlig integration af kodeændringer foretaget af udviklere i den delte filial/depot. Koden, der skal integreres, skal gennemgå en verificeret test for at sikre, at den ikke bryder applikationen. Det er først, når testen består, at den integreres
For at forstå dette, lad os forestille os et scenarie i det virkelige liv, hvor der er et team på 10 udviklere. Disse udviklere opretter en filial lokalt, hvor de skriver kode til implementering af visse funktioner. I stedet for at sende pull-anmodninger, når de er helt færdige med funktionen, vælger de at sende pull-anmodninger, da de laver små ændringer. Et eksempel på en sådan ændring vil være oprettelsen af en ny modal, forudsat at udvikleren arbejder på en funktion, der giver brugerne mulighed for at administrere individuelle opgaver i applikationen. I stedet for at vente, indtil opgavefunktionen er fuldført, for at overholde et kontinuerligt integrationsmønster, skubber udvikleren denne lille ændring (i forhold til det, hun arbejder på) og opretter en pull-anmodning om at flette til koden.
Før denne nye ændring integreres, skal der køres en række tests.
Softwareingeniørteams gør brug af værktøjer som f.eks Travis CI at skabe disse integrationsprocesser og tests. Med værktøjer som disse automatiseres testene, så de kører, så snart en pull-anmodning sendes til den målgren, der er valgt under opsætningen.
Resultaterne af testene genereres, og udvikleren, der har oprettet pull-anmodningerne, kan se resultaterne og foretage nødvendige ændringer. Fordelene ved at holde sig til dette mønster med at integrere kode så lidt som muligt og have en verificeret test til at køre er;
- Det bliver muligt for det involverede team at vide, hvad der forårsagede, at byggeprocessen eller testen mislykkedes. Dette reducerer muligheden for at sende en fejl til produktion.
- Hvis teamet automatiserer processen, vil de have luksusen af tid til at fokusere på at være produktive.
Det vigtige at bemærke i denne praksis er, at det tilskynder teamet til at skubbe kode til hovedgrenen ofte. At gøre dette vil være ineffektivt, hvis andre medlemmer af teamet ikke trækker sig fra hovedgrenen for at opdatere deres lokale lager.
Typer af tests
I at skrive test, der vil være en del af integrationsprocessen, er her nogle, der kan implementeres i processen:
- Integration – den kombinerer individuelle enheder af softwaren og tester dem som en gruppe.
- Enhed – den tester for individuelle enheder eller komponenter i softwaren som metoder eller funktioner.
- UI – hævder, at softwaren fungerer godt fra brugerens perspektiv.
- Accept – tester, at softwaren lever op til forretningskrav.
Det er vigtigt at bemærke, at du ikke behøver at teste alle disse, da en håndfuld af dem muligvis allerede er dækket af koden skrevet af udvikleren.
Værktøjer til kontinuerlige integrationer
Uden at gå i dybden, er her værktøjer, som du kan begynde at gøre brug af i dine nuværende eller nye projekter;
- Travis CI – kendt i open source-verdenen og lover dig at få din kode testet problemfrit på få minutter.
- Cirkel CI – giver dig kraft, fleksibilitet og kontrol til at automatisere din pipeline fra kontrol til implementering.
- Jenkins – leverer hundredvis af plugins til at understøtte opbygning, implementering og automatisering af ethvert projekt.
Hvis du er ny til Jenkins, vil jeg foreslå at tage dette Udemy kursus at lære CI med Java og .NET.
Kontinuerlig implementering
Hvor godt vil det være, hvis den funktion, du bygger, sidder i depotet i uger eller måneder, før den implementeres i produktionsmiljøet. Så meget som ingeniørteams kan arbejde hen imod at integrere små ændringer i hovedgrenen, når det sker, kan de også skubbe disse ændringer til produktionsmiljøet så hurtigt som muligt.
Målet, når man praktiserer kontinuerlig implementering, er at få ændringerne lavet ned til brugerne, så snart udviklerne integrerer disse ændringer i hovedgrenen.
Ligesom i tilfældet med kontinuerlig integration, når der gøres brug af kontinuerlig implementering, opsættes der automatiske test og kontroller for at sikre, at de nyligt integrerede ændringer er verificeret. Implementeringen sker kun, når disse tests består.
For at et team kan drage fordel af praksis med kontinuerlig implementering, skal de have følgende på plads;
- Automatiseret test er den væsentlige rygrad i al kontinuerlig ingeniørpraksis. I tilfælde af kontinuerlig implementering skal koden, der skal implementeres, leve op til den standard, som teamet har indført for, hvad de har til hensigt at skubbe ud til slutbrugerne. Ideelt set, hvis en ny ændring er under tærsklen, bør testen mislykkes og ikke blive integreret. Ellers bliver det integreret.
- På trods af at der er automatiserede tests back-to-back, er det muligt, at nogle fejl vil glide ind i produktionsmiljøet. Til dette er det nødvendigt, at teamet er i stand til at fortryde en ændring, der er foretaget – fortryde en implementering. Dette skulle vende produktionskoden tilbage til, hvad den var, før den nye ændring blev foretaget.
- Overvågningssystemer er nødvendige for at holde styr på ændringer, der er blevet skubbet til produktionsmiljøet. Sådan kan teamet være i stand til at spore fejl, som brugere støder på, når de gør brug af de implementerede ændringer.
De nævnte værktøjer til kontinuerlig integration giver dig også funktionaliteten til at opsætte et kontinuerligt udrulningssystem. Der er masser af dem, du også kan læse dig til.
Konklusion
Et udviklingsteams produktivitet er afgørende for virksomhedens succes. For at sikre, at de er produktive, skal praksis, der tilskynder til dette, vedtages. Kontinuerlig integration og implementering er eksempler på sådan praksis.
Med kontinuerlig integration kan teams skubbe så meget kode som muligt dagligt. Når dette er opnået, bliver det nemt at implementere de nyligt tilføjede ændringer til brugeren så hurtigt som muligt. Implementering af disse ændringer gør det muligt at få feedback fra brugerne. I sidste ende vil virksomheden være i stand til at innovere baseret på den modtagne feedback, hvilket er en win-win for alle.
Du kan også lære, hvordan du skalerer op og optimerer CI/CD.
Hvis du er udvikler og interesseret i at lære CI/CD, så tjek dette genialt kursus.
Nydt at læse artiklen? Hvad med at dele med verden?