Menu

Continue integratie in DevOps

continuous integration devops

Probeer Ons Instrument Voor Het Oplossen Van Problemen

Wat is continue integratie in DevOps?

Tot dusver hebben we deel 1 en deel 2 van dit onderwerp behandeld in onze vorige sessies en momenteel in deel 3.

handmatige testvragen en antwoorden voor ervaren

Tot deel 2 hebben we ingegaan op het mensen- en procesaspect van DevOps, namelijk samenwerking en focus op het gemeenschappelijke doel, de gemeenschappelijke mindset en het gemeenschappelijke denken in het team dat helpt om de doelstellingen van DevOps te bereiken.

Continue integratie in devlops

In onze laatste tutorial hebben we kennis opgedaan over Hoe u samenwerking in DevOps ontwikkelt ​

Bekijk => Ultieme gids over DevOps

Continue integratie, continu testen, continue implementatie en continue levering zijn de belangrijkste technische aspecten van DevOps.

VIDEO Deel 3 Blok 1: Continue integratie- 12 minuten 20 seconden

Vertaling:

Als laatstedeels hebben we DevOps-praktijken geleerd, waaronder we hebben geleerd welke delen van agile-principes door DevOps-praktijken worden overgenomen.

Hoe worden de doelstellingen van DevOps bereikt door middel van deze principes?

We hebben het belang van versiebeheer, automatisering en levering van kleine waardestijgingen aan klanten en de voordelen ervan bestudeerd.

Wat is samenwerking in de context van DevOps en hoe bereiken we dat?

Tot nu toe hebben we gesproken over het mensen- en procesaspect van DevOps, dat is samenwerking en focus op een gemeenschappelijk doel en een gemeenschappelijke mindset en gemeenschappelijk denken binnen het team dat helpt om de doelstellingen van DevOps te bereiken, laten we nu eens kijken naar enkele technische aspecten van DevOps , wat een DevOps-release mogelijk maakt.

Het zijn continue integratie, continue levering en implementatie en continu testen.

Laten we als onderdeel van blok 1 van deel 3 eerst bestuderen ‘Continue integratie’.

Wat is continue integratie?

Continue integratie -> CI -> set van processen -> Build pipeline / CI Pipeline

Continue integratie, in DevOps kortweg ‘CI’ genoemd, is een belangrijk proces of een reeks processen die wordt gedefinieerd en uitgevoerd als onderdeel van een pijplijn genaamd ‘Build Pipeline’ of ‘CI Pipeline’.

We weten dat we in de DevOps-praktijk één versiebeheertool hebben voor zowel het Development- als het Operations-team, waar de code van iedereen wordt gedeponeerd als een mastercodebasis en dit stelt het team in staat parallel te werken.

Dus, continue integratie in DevOps is niets anders dan het samenvoegen van individuele ontwikkelaarscode in de hoofdkopie van de code naar de hoofdtak waar versiebeheer wordt onderhouden. Er is geen beperking op het aantal keren dat de codesamenvoeging binnen een dag moet plaatsvinden.

Zoals en wanneer de ontwikkelaar zijn code incheckt bij het versiebeheer, begint onmiddellijk het proces van CI-kick.

hoe je een dubbel gelinkte lijst maakt in java

Het CI-proces omvat,

  1. Het samenvoegen van alle Developers-code naar de hoofdregel,
  2. Een build activeren,
  3. De code compileren en een build maken en…. Als laatste
  4. Uitvoeren van de unit-test.

Continue integratie is dus een proces van het samenvoegen van alle code van de ontwikkelaar op een centrale locatie en het valideren van elk van hun samenvoegingen met een geautomatiseerde build en test.

Om technisch uit te leggen wat er gebeurt tijdens CI is,

Er zal een server zijn voor continue integratie die het CI-tool , die de versiebeheer-tool blijft volgen voor het inchecken van de code en zodra een check-in wordt gevonden, wordt de geautomatiseerde compilatie geactiveerd, worden unit-tests gebouwd en uitgevoerd, samen met statische code-analyse en een basisniveau van geautomatiseerde beveiligingstests .

De verschillende tools om de geautomatiseerde tests uit te voeren, zoals Jenkins, TestNG, NUnit om unit-tests uit te voeren, Sonar om statische code-analyse uit te voeren en versterken om de beveiligingstests uit te voeren, al deze tools zullen worden geïntegreerd met de CI-pijplijn .

De volledige CI-pijplijn is dus een geautomatiseerd proces zonder handmatige tussenkomst en loopt binnen enkele seconden of minuten.

Het grote voordeel van de CI is dus de snelle feedback die de ontwikkelaars binnen de kortste keren krijgen.

  1. De CI wordt uitgevoerd nadat de ontwikkelaar de code heeft ingecheckt en de resultaten binnen enkele seconden weggooit. Het stelt de ontwikkelaars dus in staat onmiddellijk te weten of zijn of haar code met succes is gebouwd of gebroken.
  2. Het laat de ontwikkelaar ook weten of zijn code met succes is geïntegreerd met de code van de ander of kapot is gegaan, iets dat een ander teamlid heeft gedaan met een ander deel van de codebasis. Daarom voert CI de snellere code-analyse uit en maakt de latere samenvoegingen eenvoudiger en foutloos.

CI is dus een geautomatiseerd proces, waarbij de build wordt getriggerd bij elke code-check-in, wordt gecompileerd, build wordt gemaakt en geautomatiseerde unit-tests worden uitgevoerd op de build.

We kunnen CI ook bellen als de COP of het proces om te controleren of de code van iedereen in het team een ​​goede of geldige code is of niet, omdat het CI-proces onmiddellijk compileert en bouwt bij elke check-in en fouten genereert als het een slechte code is, of het kan niet worden samengesteld of kan de testgevallen van geautomatiseerde eenheden niet doorstaan.

Wat zijn de voordelen van CI?

Allereerst is het hele CI-proces een geautomatiseerd proces en minimaliseert het daarom de menselijke fout door de lange, bug-inducerende handmatige samenvoegingen te verminderen.

Een willekeurig aantal mensen kan hun code op elk gewenst moment per dag inchecken zonder te wachten tot anderen hun codering hebben voltooid, wachten tot ze klaar zijn met inchecken en later inchecken. Dus, CI verwijdert de afhankelijkheid of verwijdert de wachttijd van anderen die inchecken.

Zo hoeven teamleden niet te wachten tot de andere teamleden klaar zijn met inchecken en kunnen ze dus parallel werken.

Elke check-in stopt gewoon niet bij het ophalen van de versiecontrole, maar wordt meteen gekwalificeerd door de build-formatie en geautomatiseerd testen. Elke check-in wordt dus bij de root zelf gevalideerd voor verdere verwerking.

Er is geen kans om iemands code te missen, omdat de code van iedereen wordt ingecheckt in de hoofdkopie met het tijdstempel en dus correct wordt geregistreerd.

Het hele proces van compileren, bouwen en testen verloopt in enkele seconden en dus behoorlijk sneller en sneller en bespaart veel tijd en helpt daarmee om de DevOps-doelstelling van sneller leveren over een periode van enkele uren te bereiken.

Omdat het hele proces van bouwen en testen enkele seconden tot minuten duurt, is de feedback op de code van individuen erg snel en hoeven we niet rond te rennen om erachter te komen wiens code de build heeft verbroken of het defect heeft veroorzaakt, zoals bij elke check-in geeft het de uitvoer van succes of mislukking en geeft het gebied van mislukking aan als er een fout is.

Hierdoor kan de ontwikkelaar de kleine hoeveelheid code met tussenpozen inchecken, misschien zelfs een enkele regel code, om er zeker van te zijn dat deze foutloos is en de ontwikkelaar erop kan vertrouwen dat hun code goed is en ook anderen niet kapot maakt code. Dit helpt dus in totaal om de kwaliteit van de code te verbeteren.

Laten we hier even pauzeren en laten we de continue levering en continu testen oppikken in de komende videozelfstudies.

PREV-zelfstudie ​ VOLGENDE zelfstudie

Aanbevolen literatuur

^