Forståelse af kontinuerlig integration og kontinuerlig implementering

Hørte CI / CD, men er 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 virksomheden (ofte kaldet brugere / klienter) er det vigtigt, at produkterne er fejlfri.

Den typiske tilgang, som softwareingeniører fulgte, er at arbejde i grene og oprette en pull-anmodning, der opdaterer mastergrenen med den nye opdatering, der er foretaget. Vi har vedtaget praksis med at skrive test som et middel til at sikre, at de nye ændringer ikke introducerer fejl. Når udviklere i de fleste tilfælde arbejder med en funktion, opretter de ofte ikke en pull-anmodning, før de er færdig med funktionen. Hvad der sker, når de er klar, er det;

  • De bruger en masse tid på at prøve at bringe deres codebase opdateret med de ændringer, der er sket i produktionsgrenen, mens de arbejdede.
  • Ved at gøre dette er de nødt til at løse en række fusionskonflikter.
  • Der er også muligheden for, at de bryder produktionsgrenen, hvilket fortsætter med at påvirke dem, der trækker fra filialen, før problemet ses og løses.

Hvis du nogensinde har været i denne situation, er du enig i, at det kan være en smerte – ingen vil gerne tilbringe deres arbejdsdag som denne.

Hvad er løsningen?

Kontinuerlig integration

https://www.youtube.com/watch?v=HnWuIjUw_Q8

For at forhindre de scenarier, jeg nævnte ovenfor; ingeniørhold kan vedtage den kaldte praksis 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 er bestået, at den er integreret

For at forstå dette, lad os forestille os et virkelighedsscenarie, 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 styre individuelle opgaver i applikationen. I stedet for at vente, indtil opgavefunktionen er afsluttet, for at overholde et kontinuerligt integrationsmønster, skubber udvikleren denne lille ændring (sammenlignet med hvad hun arbejder på) og opretter en pull-anmodning om at flette til koden.

Inden denne nye ændring integreres, skal en række tests køres.

Software engineering teams gør brug af værktøjer som Travis CI at oprette disse integrationsprocesser og test. Med værktøjer som disse er testene automatiseret, så de kører, så snart en anmodning om træk sendes til den målgren, der er valgt under opsætningen.

Resultaterne af testene genereres, og udvikleren, der oprettede pull-anmodninger, kan se resultaterne og foretage nødvendige ændringer. Fordelene ved at holde sig til dette mønster ved at integrere kode så lidt som muligt og have en verificeret test, der skal køres, er;

  • Det bliver muligt for det involverede team at vide, hvad der har forårsaget byggeprocessen eller testen til at mislykkes. Dette reducerer muligheden for at sende en fejl til produktion.
  • Hvis teamet automatiserer processen, har de tid til at fokusere på at være produktive.

Den vigtige ting at bemærke i denne praksis er, at det tilskynder teamet til ofte at skubbe kode til hovedgrenen. Dette vil være ineffektivt, hvis andre medlemmer af teamet ikke trækker fra hovedgrenen for at opdatere deres lokale depot.

Typer af test

Når du skriver test, der vil være en del af integrationsprocessen, er her nogle, der kan implementeres i processen:

  • Integration – det kombinerer individuelle enheder af softwaren og tester dem som en gruppe.
  • Enhed – det tester for individuelle enheder eller komponenter i softwaren som metoder eller funktioner.
  • UI – hævder, at softwaren fungerer godt ud fra brugerens perspektiv.
  • Accept – test, at softwaren opfylder 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.

Kontinuerlige integrationsværktøjer

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 at du tester din kode problemfrit på få minutter.
  • Cirkel CI – giver dig kraft, fleksibilitet og kontrol til at automatisere din rørledning fra kontrol til implementering.
  • Jenkins – giver hundreder af plugins til støtte for opbygning, implementering og automatisering af ethvert projekt.

Hvis du er ny med 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 for at integrere små ændringer i hovedgrenen, som 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 til brugerne, så snart udviklerne integrerer disse ændringer i hovedgrenen.

Ligesom i tilfælde af kontinuerlig integration, når der bruges kontinuerlig implementering, er der oprettet automatiske test og kontroller for at sikre, at de nyligt integrerede ændringer verificeres. Implementeringen sker kun, når disse test er bestået.

For at et team kan drage fordel af praksis ved kontinuerlig implementering, skal de have følgende på plads;

  • Automatiseret test er den væsentligste rygrad i al kontinuerlig teknik. I tilfælde af kontinuerlig implementering skal koden, der skal implementeres, opfylde den standard, holdet har indført for, hvad de agter at skubbe ud til slutbrugerne. Hvis en ny ændring er under tærsklen, bør ideelt set mislykkes og ikke integreres. Ellers bliver det integreret.
  • På trods af at have automatiserede tests back-to-back, er det muligt, at nogle bugs vil glide ind i produktionsmiljøet. Til dette er det nødvendigt, at holdet er i stand til at fortryde en ændring, der er foretaget – fortryd en indsættelse. 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 skubbet til produktionsmiljøet. Dette er, hvordan teamet kan være i stand til at spore fejl, som brugerne støder på, når de bruger de implementerede ændringer.

De værktøjer, der er nævnt til kontinuerlig integration, giver dig også funktionaliteten til at oprette et kontinuerligt implementeringssystem. Der er masser af dem, som du også kan læse videre på.

Konklusion

Produktiviteten i et udviklingshold er afgørende for virksomhedens succes. For at sikre, at de er produktive, skal der anvendes fremgangsmåder, der tilskynder til dette. Kontinuerlig integration og implementering er eksempler på sådan praksis.

Med kontinuerlig integration kan hold skubbe så meget kode som muligt dagligt. Når dette opnås, bliver det let 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, som er en win-win for alle.

Hvis du er en udvikler og er interesseret i at lære CI / CD, så tjek dette strålende kursus.

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me
    Like this post? Please share to your friends:
    Adblock
    detector
    map