Wat is Continuous Integration?

CI, CD en continue implementatie zijn elk een cruciaal onderdeel van de levenscyclus van de softwarerelease, inclusief DevOps-processen.

Als algemene regel wordt CI gebruikt in combinatie met flexibele softwareontwikkeling, waarmee een organisatie taken bij elkaar kan brengen in een lijst en een producttraject. Zodra de taken zijn beschreven, worden deze voor de uitvoering aan verschillende teamleden beschreven. De verschillende codes worden vervolgens samengevoegd in een hoofdcodeopslagplaats.

CD is het tweede deel van het proces. Het gaat om het bundelen van code, die vervolgens klaar is om aan eindgebruikers te worden geleverd. In deze stap van het proces worden meestal geautomatiseerde tools uitgevoerd die een artefact genereren, waardoor het op elk gewenst moment kan worden geïmplementeerd bij eindgebruikers.

In de laatste fase van het proces, continue implementatie, wordt het softwareproduct automatisch gestart voor eindgebruikers, wat betekent dat de integratie en levering zijn geslaagd. De automatisering maakt gebruik van scripts of tools die het softwareproduct overdragen naar openbare servers of andere openbare distributiemethoden. In een sterk geautomatiseerde en goed beheerde omgeving worden deze implementaties automatisch uitgevoerd zodra het product wordt geleverd (dus continu). Sommige teams of sommige producten kunnen in plaats daarvan op specifieke tijden worden ingezet of nadat andere processen en controles zijn voltooid.

Door de minimalisering van codebureaucratie kunnen DevOps en flexibele workflows effectief en soepel werken, van de ontwikkeling van nieuwe code tot het einde van de cyclus. CI kan een bedrijf helpen schalen wanneer het afhankelijkheden verwijdert die de ontwikkeling van afzonderlijke functies in de weg staan. Hoewel een ontwikkelaar in een silo werkt, kan hij/zij dit doen in de wetenschap dat de code wordt geïntegreerd in de rest van de codeopslagplaats.

Krijg sneller feedback over zakelijke beslissingen. Dit betekent dat productteams hun ideeën kunnen testen en beter kunnen omgaan met iteratief productontwerp. Veranderingen worden snel, meetbaar en succesvol zijn, en bugs worden snel aangepakt en gecorrigeerd.

Engineering-teams kunnen beter communiceren en ter verantwoording worden geroepen, waardoor betere communicatie in een DevOps-team mogelijk is. Teams hebben de mogelijkheid om code die door andere teamleden is geschreven, te bekijken en erop te reageren. Dit biedt ook de mogelijkheid om aan toekomstige code samen te werken met andere ontwikkelaars.

Code wordt uitgevoerd via versiebesturingssoftware, zoals apache subversion of git, en de commit history van de softwarecode wordt vastgelegd zodat deze indien nodig kan worden gewijzigd.

Ontwikkelaars bouwen hun code uit en de code wordt doorgegeven via het versiehistoriesysteem. De code wordt vervolgens teruggestuurd naar de buildfase voor compilatie.

Software wordt getest, inclusief unittesten waarbij stukjes broncode worden getest . De staging-fase begint na succesvolle tests, wat betekent dat de code klaar is om in het staging-proces te worden geïmplementeerd. Hier wordt de code bekeken en afgemaakt vóór de laatste testfase.

Nadat de software in de staging-omgeving is geweest, worden er automatische tests uitgevoerd die zijn opgesteld voor de software. Zodra de software slaagt voor de automatische tests, wordt deze naar de implementatiefase verzonden.

Nadat de automatische tests zijn uitgevoerd, wordt de software in productie genomen. Als er fouten optreden tijdens de testfase of de daaropvolgende implementatie, keert de software terug naar de versiecontroleprocedure en wordt het gecontroleerd op fouten. Als er fouten worden gevonden, worden deze gecorrigeerd.

Elk artefact dat nodig is om een project te bouwen, moet in een centrale codeopslagplaats worden geplaatst. Hierdoor kunnen geïntegreerde wijzigingen worden onderhouden in plaats van dat afzonderlijke versies tegelijkertijd worden onderhouden.

Idealiter is er één opdracht die een systeem kan uitbouwen. Dit omvat het automatiseren van integratie, die in een productachtige omgeving kan worden geïmplementeerd. Er zijn veel gevallen waarin het script binaries samenstelt tijdens het genereren van webpagina's, distributiemedia, statistieken en webpagina's.

Elke test moet worden uitgevoerd om te bevestigen dat deze zich gedraagt zoals verwacht.

De kans op tegenstrijdige veranderingen kan exponentieel worden verkleind wanneer iedereen zich regelmatig inzet. Met dagelijkse buy-in kunnen ontwikkelaars problemen of noodzakelijke wijzigingen in de code identificeren, waarna ze de veranderingen communiceren. Wanneer het werk van een week zich opstapelt, kan dit nog meer bijdragen aan het niet onderscheppen of te groot worden van problemen, daarom is dagelijkse inzet noodzakelijk.

Commits moeten worden gebouwd volgens de huidige werkversie om te controleren of ze correct werken. Meestal wordt Automated Continuous Integration (ACI) gebruikt, maar het kan ook handmatig worden uitgevoerd. ACI gebruikt een daemon om het revisiebeheersysteem te controleren op aangebrachte wijzigingen, waarna het buildproces automatisch wordt uitgevoerd.

Elke build moet zo snel mogelijk worden uitgevoerd om problemen met de integratie te voorkomen of problemen snel te identificeren.

Een testomgeving kan storingen veroorzaken in een getest systeem als deze in een productieomgeving worden geïmplementeerd. Het opzetten van een replica van de productieomgeving kan storingen voorkomen, omdat een productieomgeving kan verschillen van een testomgeving. Een afzonderlijke staging-omgeving moet een schaalbare versie zijn die de samenstelling van technologiestacks onderhoudt en tegelijkertijd de kosten verlaagt.

Belanghebbenden en testers moeten het werk mogelijk zien, dus het is het beste om de builds direct beschikbaar te houden om de hoeveelheid noodzakelijke aanpassingen te verminderen als een functie opnieuw moet worden gebouwd. Door vroeg te testen kan ook de kans op fouten die te ver in het proces doorlopen, worden vermeden.

Als een build stuk gaat, is deze meestal gemakkelijk te vinden. CI helpt een team bij het identificeren van de aangebrachte wijzigingen en het teamlid dat de wijzigingen heeft aangebracht, wat kan bijdragen aan transparantie en productiviteit.

Zelfs nadat een build is voltooid, worden op de meeste CI-systemen scripts uitgevoerd. Het is mogelijk om een script te schrijven om de toepassing te implementeren op een live testserver die voor iedereen zichtbaar is. CI vraagt dat software in productie wordt genomen met extra automatisering om terugval of defecten te voorkomen.

Het is raadzaam om de testdekking voortdurend te ontwikkelen en te verbeteren zodra een project in de CI-pijplijn is opgezet. Er moeten tests worden uitgevoerd die bij elke nieuwe functie horen en die de CI-pijplijn omlaag brengen om te controleren of de nieuwe code werkt zoals verwacht.

Pull-aanvragen zijn een cruciaal onderdeel van CI. De meeste softwareontwikkelaars oefenen een pullaanvraag- en codebeoordelingsproces uit. Een pull-aanvraag is een uitstekende gelegenheid om de CI-pijplijn te starten en de stappen van geautomatiseerde goedkeuring te doorlopen. Handmatige goedkeuring wordt ook toegevoegd op het moment van een pullaanvraag, wanneer een niet-belanghebbende een controle van de code kan uitvoeren. Dit biedt de niet-belanghebbende de mogelijkheid om bewerkingen te identificeren of de pullaanvraag goed te keuren of af te wijzen.

Het is van cruciaal belang om de uitvoeringssnelheid van de CI-pijplijn te optimaliseren, omdat het een veelgebruikt proces is. Vertragingen in de workflow kunnen leiden tot problemen tijdens groeiende functiereleases, codebases en teamgroottes. Meet voortdurend de CI-pijplijn om ervoor te zorgen dat deze wordt geoptimaliseerd.

Er is een snellere CI-feedbacklus wanneer er een snellere CI-pijplijn is. Ontwikkelaars kunnen veranderingen doorvoeren en experimenteren met een gebruikersbeleving, bugs snel oplossen en de uitvoeringssnelheid verhogen, wat voordelen ten opzichte van de concurrentie en een hogere kwaliteit oplevert.

U kunt CI/CD gebruiken bij het bouwen van apps op het ServiceNow-platform. U kunt uw CI/CD-tools ook verbinden met het DevOps-product van ServiceNow om het werk dat via de CI/CD-pijplijn loopt te koppelen aan het werk dat wordt beheerd in ServiceNow. Het ServiceNow DevOps-product kan vele voordelen bieden voor het CI/CD-proces, of u nu voortbouwt op het ServiceNow-platform of buiten ServiceNow in tools zoals Azure DevOps, GitLab of Jenkins.

Beheer codewijzigingen effectief voor meerdere ontwikkelaars wanneer ze Git repo-integratie gebruiken en een koppeling maken tussen werkitems zoals gebruikersverhalen en de commits in de repo. Met de extra verbinding van commits om resultaten en wijzigingen in ServiceNow te testen, krijgt u een volledig end-to-end overzicht van de pijplijn.

Automatiseer het maken, goedkeuren en implementeren van wijzigingen en stap sneller en efficiënter over van ontwikkeling en testen naar productie.

Lever toepassingen sneller. Dit helpt teams om sneller en regelmatiger op feedback te reageren.

Rapporteer over de gehele pijplijn of waardestroom van idee tot productie. Communiceer onderling tussen teams, vergelijk de prestaties van verschillende tools en identificeer knelpunten en los deze op.