Wat is CI / CD? Continue integratie en continue levering uitgelegd

Continue integratie (CI) en continue levering (CD) belichamen een cultuur, een reeks werkingsprincipes en een verzameling praktijken waarmee applicatieontwikkelingsteams codewijzigingen vaker en betrouwbaarder kunnen doorvoeren. De implementatie wordt ook wel de CI / CD- pijplijn genoemd. 

CI / CD is een van de best practices voor devops-teams om te implementeren. Het is ook een flexibele methodologie, aangezien het softwareontwikkelingsteams in staat stelt zich te concentreren op het voldoen aan zakelijke vereisten, codekwaliteit en beveiliging, omdat implementatiestappen geautomatiseerd zijn.

CI / CD gedefinieerd

Continue integratie  is een coderingsfilosofie en een reeks werkwijzen die ontwikkelteams ertoe aanzetten om kleine wijzigingen door te voeren en regelmatig code in te checken voor versiebeheeropslagplaatsen. Omdat voor de meeste moderne applicaties code moet worden ontwikkeld op verschillende platforms en tools, heeft het team een ​​mechanisme nodig om de wijzigingen te integreren en te valideren.

Het technische doel van CI is om een ​​consistente en geautomatiseerde manier te vinden om applicaties te bouwen, verpakken en testen. Met consistentie in het integratieproces is de kans groter dat teams vaker codewijzigingen doorvoeren, wat leidt tot betere samenwerking en softwarekwaliteit.

De continue levering  begint waar de continue integratie eindigt. CD automatiseert de levering van applicaties aan geselecteerde infrastructuuromgevingen. De meeste teams werken met meerdere omgevingen behalve de productie, zoals ontwikkel- en testomgevingen, en CD zorgt ervoor dat er een geautomatiseerde manier is om codewijzigingen naar hen te pushen.

CI / CD-tools helpen bij het opslaan van de omgevingsspecifieke parameters die bij elke levering moeten worden verpakt. CI / CD-automatisering voert vervolgens alle noodzakelijke serviceaanroepen uit naar webservers, databases en andere services die mogelijk opnieuw moeten worden gestart of volg andere procedures wanneer toepassingen worden geïmplementeerd.

Continue integratie en continue levering vereisen  continue testen,  omdat het doel is om gebruikers van hoge kwaliteit applicaties en code te leveren. Continu testen wordt vaak geïmplementeerd als een reeks geautomatiseerde regressie-, prestatie- en andere tests die worden uitgevoerd in de CI / CD-pijplijn.

Een volwassen CI / CD devops-praktijk heeft de mogelijkheid om continue implementatie te implementeren waarbij applicatiewijzigingen door de CI / CD-pijplijn lopen en passerende builds rechtstreeks in productieomgevingen worden geïmplementeerd. Teams die aan continue levering werken, kiezen ervoor om in productie te gaan volgens een dagelijks of zelfs uurlijks schema, hoewel continue levering niet altijd optimaal is voor elke zakelijke toepassing.  

Gerelateerde video: Hoe code sneller te leveren met CI / CD

Hoe continue integratie de samenwerking en kwaliteit verbetert

Continue integratie is een ontwikkelingsfilosofie die wordt ondersteund door procesmechanica en enige automatisering. Bij het oefenen van CI committeren ontwikkelaars hun code regelmatig in de versiebeheerrepository en de meeste teams hebben een minimale standaard voor het doorvoeren van code op zijn minst dagelijks. De grondgedachte hierachter is dat het gemakkelijker is om defecten en andere softwarekwaliteitsproblemen te identificeren met kleinere codeverschillen in plaats van grotere die gedurende lange perioden zijn ontwikkeld. Wanneer ontwikkelaars werken aan kortere commit-cycli, is het bovendien minder waarschijnlijk dat meerdere ontwikkelaars dezelfde code bewerken en een samenvoeging vereisen bij het vastleggen.

Teams die continue integratie implementeren, beginnen vaak met de configuratie van versiebeheer en oefendefinities. Hoewel het inchecken van code vaak wordt gedaan, worden functies en fixes geïmplementeerd voor zowel korte als langere tijdsbestekken. Ontwikkelteams die continue integratie oefenen, gebruiken verschillende technieken om te bepalen welke functies en code klaar zijn voor productie.

Veel teams gebruiken functievlaggen , een configuratiemechanisme om functies en code tijdens runtime in of uit te schakelen. Functies die nog in ontwikkeling zijn, worden verpakt met functievlaggen in de code, geïmplementeerd met de master branch naar productie en uitgeschakeld totdat ze klaar zijn om te worden gebruikt. Volgens een recent onderzoek meldt 63 procent van de teams die functievlaggen gebruiken, betere tests en software van hogere kwaliteit. Functievlaggingstools zoals CloudBees Rollout, Optimizely Rollouts en LaunchDarkly integreren met CI / CD-tools en maken configuraties op functieniveau mogelijk.

Een andere techniek voor het beheren van functies is  vertakking van versiebeheer . Een vertakkingsstrategie zoals Gitflow wordt geselecteerd om protocollen te definiëren over hoe nieuwe code wordt samengevoegd tot standaardvertakkingen voor ontwikkeling, testen en productie. Er worden extra functietakken gemaakt voor degenen die langere ontwikkelingscycli nodig hebben. Als de feature compleet is, kunnen de ontwikkelaars de wijzigingen van feature branches samenvoegen naar de primaire ontwikkeling branch. Deze benadering werkt goed, maar het kan moeilijk te beheren worden als er veel functies tegelijkertijd worden ontwikkeld.

Het buildproces zelf wordt vervolgens geautomatiseerd door alle software, database en andere componenten te verpakken. Als u bijvoorbeeld een Java-toepassing aan het ontwikkelen was, zou CI alle statische webserverbestanden, zoals HTML, CSS en JavaScript, samen met de Java-toepassing en eventuele databasescripts verpakken.

CI verpakt niet alleen alle software- en databasecomponenten, maar de automatisering zal ook unit-tests en andere tests uitvoeren. Deze tests geven ontwikkelaars feedback dat hun codewijzigingen de bestaande unit-tests niet hebben verbroken.

Met de meeste CI / CD-tools kunnen ontwikkelaars builds op aanvraag starten, geactiveerd door code-commits in de versiebeheerrepository of volgens een bepaald schema. Teams moeten het buildschema bespreken dat het beste werkt voor de grootte van het team, het verwachte aantal dagelijkse commits en andere toepassingsoverwegingen. Een best practice om ervoor te zorgen dat commits en builds snel zijn, anders kan het de voortgang belemmeren van teams die proberen om snel te coderen en regelmatig te committeren.

Continu testen gaat verder dan testautomatisering

Geautomatiseerde testframeworks helpen kwaliteitsborgingsingenieurs verschillende soorten tests te definiëren, uit te voeren en te automatiseren die ontwikkelingsteams kunnen helpen te weten of een softwareconstructie slaagt of mislukt. Ze bevatten functionaliteitstests die aan het einde van elke sprint worden ontwikkeld en samengevoegd tot een regressietest voor de hele applicatie. Deze regressietests informeren het team vervolgens of een codewijziging mislukt is voor een of meer van de tests die zijn ontwikkeld in alle functionele gebieden van de applicatie waar er testdekking is.

Een best practice is om ontwikkelaars in staat te stellen en te verplichten om alle of een subset van regressietests in hun lokale omgevingen uit te voeren. Deze stap zorgt ervoor dat ontwikkelaars alleen code aan versiebeheer vastleggen nadat regressietests de codewijzigingen hebben doorgegeven.

Regressietesten zijn nog maar het begin. Prestatietests, API-tests, analyse van statische code, beveiligingstests en andere testformulieren kunnen ook worden geautomatiseerd. De sleutel is om deze tests te kunnen activeren via de opdrachtregel, webhook of webservice en dat ze reageren met statuscodes met succes of mislukking.

Als het testen eenmaal is geautomatiseerd, houdt continu testen in dat de automatisering is geïntegreerd in de CI / CD-pijplijn. Sommige unit- en functionaliteitstests kunnen in CI worden geïntegreerd die problemen signaleren vóór of tijdens het integratieproces. Tests die een volledige leveringsomgeving vereisen, zoals prestatie- en beveiligingstests, worden vaak geïntegreerd op de cd en uitgevoerd nadat builds zijn geleverd aan doelomgevingen.

De CD-pijplijn automatiseert wijzigingen in meerdere omgevingen

Continue levering is de automatisering die applicaties naar leveringsomgevingen pusht. De meeste ontwikkelingsteams hebben doorgaans een of meer ontwikkel- en testomgevingen waar applicatiewijzigingen worden uitgevoerd voor testen en beoordelen. Een CI / CD-tool zoals Jenkins, CircleCI, AWS CodeBuild, Azure DevOps, Atlassian Bamboo of Travis CI wordt gebruikt om de stappen te automatiseren en rapportage te verstrekken.

Een typische CD-pijplijn heeft bouw-, test- en implementatiefasen. Meer geavanceerde pijplijnen omvatten veel van deze stappen:

  • Code uit versiebeheer halen en een build uitvoeren.
  • Het uitvoeren van alle vereiste infrastructuurstappen die zijn geautomatiseerd als code om de cloudinfrastructuur op te staan ​​of af te breken.
  • Code verplaatsen naar de beoogde computeromgeving.
  • De omgevingsvariabelen beheren en configureren voor de doelomgeving.
  • Applicatiecomponenten pushen naar de juiste services, zoals webservers, API-services en databaseservices.
  • Alle stappen uitvoeren die nodig zijn om services opnieuw te starten of service-eindpunten aan te roepen die nodig zijn voor nieuwe code-pushes.
  • Continu testen en rollback-omgevingen uitvoeren als tests mislukken.
  • Logboekgegevens en waarschuwingen over de toestand van de levering.

Jenkins-gebruikers definiëren bijvoorbeeld hun pijplijnen in een Jenkins-bestand waarin verschillende fasen worden beschreven, zoals bouwen, testen en implementeren. Omgevingsvariabelen, opties, geheime sleutels, certificeringen en andere parameters worden gedeclareerd in het bestand en er wordt vervolgens in fasen naar verwezen. De postsectie behandelt foutcondities en meldingen.  

Meer geavanceerde cd's kunnen andere stappen bevatten, zoals het uitvoeren van gegevenssynchronisaties, het archiveren van informatiebronnen of het uitvoeren van applicatie- en bibliotheekpatching. CI / CD-tools ondersteunen doorgaans een markt met plug-ins. Jenkins somt bijvoorbeeld meer dan 1.500 plug-ins op die integratie met platforms van derden, gebruikersinterface, administratie, broncodebeheer en buildbeheer ondersteunen.

Zodra een CI / CD-tool is geselecteerd, moeten ontwikkelingsteams ervoor zorgen dat alle omgevingsvariabelen buiten de applicatie zijn geconfigureerd. Met CI / CD-tools kunnen deze variabelen worden ingesteld, variabelen zoals wachtwoorden en accountsleutels worden gemaskeerd en kunnen ze tijdens de implementatie voor de doelomgeving worden geconfigureerd.

CD-tools bieden ook dashboard- en rapportagefuncties. Als builds of leveringen mislukken, waarschuwen ze ontwikkelaars met informatie over de fouten. Ze integreren met versiebeheer en agile tools, zodat ze kunnen worden gebruikt om op te zoeken welke codewijzigingen en gebruikersverhalen een build hebben gemaakt.

Implementeren van CI / CD-pipelines met Kubernetes en serverloze architecturen 

Veel teams die CI / CD-pipelines in cloudomgevingen uitvoeren, gebruiken ook containers zoals Docker en orkestratiesystemen zoals Kubernetes. Containers maken het mogelijk om op standaard draagbare manieren te verpakken en te verzenden. Containers maken het eenvoudig om omgevingen met variabele workloads op te schalen of af te breken.

Er zijn veel benaderingen om containers, infrastructuur als code en CI / CD-pijplijnen samen te gebruiken. U kunt de opties verkennen door zelfstudies te doorlopen, zoals Kubernetes met Jenkins of Kubernetes met Azure DevOps.

Serverloze computerarchitecturen bieden een andere mogelijkheid voor het implementeren en schalen van applicaties. In een serverloze omgeving wordt de infrastructuur volledig beheerd door de cloudserviceprovider en verbruikt de applicatie naar behoefte bronnen op basis van de configuratie. Op AWS worden serverloze applicaties bijvoorbeeld uitgevoerd als Lambda-functies en kunnen implementaties worden geïntegreerd in een Jenkins CI / CD-pijplijn met een plug-in. 

CI / CD maakt frequentere code-implementaties mogelijk

Samenvattend: CI-pakketten en testsoftware bouwt en waarschuwt ontwikkelaars als hun wijzigingen niet door een unit-tests zijn mislukt. CD is de automatisering die wijzigingen in de infrastructuur aanbrengt en aanvullende tests uitvoert. 

CI / CD-pijplijnen zijn ontworpen voor bedrijven die applicaties regelmatig willen verbeteren en een betrouwbaar leveringsproces nodig hebben. De extra inspanning om builds te standaardiseren, tests te ontwikkelen en implementaties te automatiseren, is het fabricageproces voor het implementeren van codewijzigingen. Eenmaal geïnstalleerd, kunnen teams zich concentreren op het proces van het verbeteren van applicaties en minder op de systeemdetails voor het leveren aan computeromgevingen.

CI / CD is een best practice voor devops omdat het de verkeerde afstemming aanpakt tussen ontwikkelaars die regelmatig wijzigingen willen pushen, met bewerkingen die stabiele applicaties willen. Met automatisering kunnen ontwikkelaars vaker wijzigingen doorvoeren. Operationele teams zien meer stabiliteit omdat omgevingen standaardconfiguraties hebben, er continu wordt getest in het leveringsproces, omgevingsvariabelen worden gescheiden van de applicatie en terugdraaiprocedures worden geautomatiseerd.

De impact van het implementeren van CI / CD-pijplijnen kan worden gemeten als een devops key performance indicator (KPI). KPI's zoals implementatiefrequentie, wijzigingsdoorlooptijd en gemiddelde tijd tot herstel (MTTR) van een incident worden vaak verbeterd wanneer CI / CD met continu testen wordt geïmplementeerd. CI / CD is echter slechts één proces dat deze verbeteringen kan aandrijven, en er zijn nog andere voorwaarden om de implementatiefrequenties te verbeteren.

Om aan de slag te gaan met CI / CD, moeten ontwikkelingsteams en operationele teams samenwerken aan technologieën, praktijken en prioriteiten. Teams moeten consensus ontwikkelen over de juiste benaderingen voor hun bedrijf en technologieën, zodat zodra CI / CD is geïnstalleerd, het team aan boord is met de consequente volgende praktijken.