Zelfstudie voor continue levering - Een pijplijn voor continue levering bouwen met Jenkins

Continue levering:

Continuous Delivery is een proces waarbij codewijzigingen automatisch worden gebouwd, getest en voorbereid voor vrijgave voor productie.Ik hoop dat je genoten hebt van mijn Hier zal ik het hebben over de volgende onderwerpen:

• Wat is continue levering?
• Soorten softwaretests
• Verschil tussen continue integratie, levering en implementatie
• Wat is de behoefte aan continue levering?
• Hands-on met behulp van Jenkins en Tomcat

Laten we snel begrijpen hoe Continuous Delivery werkt.

Wat is continue levering?

Het is een proces waarbij je software zo bouwt dat deze op elk moment vrijgegeven kan worden voor productie.Beschouw het onderstaande diagram:

Laat me het bovenstaande diagram uitleggen:

• Geautomatiseerde build-scripts detecteren wijzigingen in Source Code Management (SCM) zoals Git.
• Zodra de wijziging is gedetecteerd, wordt de broncode geïmplementeerd op een speciale build-server om ervoor te zorgen dat de build niet mislukt en dat alle testklassen en integratietests goed werken.
• Vervolgens wordt de build-applicatie geïmplementeerd op de testservers (pre-productieservers) voor User Acceptance Test (UAT).
• Ten slotte wordt de applicatie handmatig geïmplementeerd op de productieservers voor release.

Voordat ik verder ga, zal het alleen maar eerlijk zijn dat ik u de verschillende soorten testen uitleg.

Soorten softwaretests:

In grote lijnen zijn er twee soorten testen:

• Blackbox-testen: Het is een testtechniek die het interne mechanisme van het systeem negeert en zich richt op de gegenereerde output tegen elke input en uitvoering van het systeem. Het wordt ook wel functioneel testen genoemd. Het wordt in principe gebruikt voor het valideren van de software.
• Whitebox-testen: is een testtechniek die rekening houdt met het interne mechanisme van een systeem. Het wordt ook structureel testen en testen van glazen dozen genoemd. Het wordt in principe gebruikt om de software te verifiëren.

Whitebox-testen:

Er zijn twee soorten testen die onder deze categorie vallen.

• Testen van een eenheid: Het is het testen van een individuele eenheid of een groep gerelateerde eenheden. Het wordt vaak door de programmeur gedaan om te testen of de eenheid die hij / zij heeft geïmplementeerd, de verwachte output produceert tegen de gegeven input.
• Integratietesten: Het is een soort testen waarbij een groep componenten aanwezig isgecombineerd om de output te produceren. Ook wordt de interactie tussen software en hardware getest of software- en hardwarecomponenten een relatie hebben. Het kan zowel onder white box-testen als onder black-box-testen vallen.

Blackbox-testen:

Er zijn meerdere tests die onder deze categorie vallen. Ik zal me concentreren opeen paar, die voor u belangrijk zijn om te weten, om deze blog te begrijpen:

• Functioneel / acceptatietesten: Het zorgt ervoor dat de gespecificeerde functionaliteit die vereist is in de systeemvereisten werkt. Het wordt gedaan om ervoor te zorgen dat het geleverde product voldoet aan de eisen en werkt zoals de klant verwacht
• Systeemtesten: Het zorgt ervoor dat door de software in verschillende omgevingen te plaatsen (bijvoorbeeld besturingssystemen) het nog steeds werkt.
• Stress testen: Het evalueert hoe het systeem zich gedraagt ​​onder ongunstige omstandigheden.
• Beta testen: Het wordt gedaan door eindgebruikers, een team buiten ontwikkeling, of het publiekelijk vrijgeven van de volledige pre-versie van het product, bekend alsbètaversie. Het doel van bètatests is om onverwachte fouten op te lossen.

Dit is voor mij het juiste moment om het verschil tussen continue integratie, levering en implementatie uit te leggen.

Verschillen tussen continue integratie, levering en implementatie:

Visuele inhoud bereikt de hersenen van een persoon op een snellere en begrijpelijkere manier dan tekstuele informatie. Dus ik ga beginnen met een diagram waarin het verschil duidelijk wordt uitgelegd:

In Continuous Integration wordt elke code-commit gemaakt en getest, maar is niet in een staat om te worden vrijgegeven. Ik bedoel, de build-applicatie wordt niet automatisch geïmplementeerd op de testservers om deze te valideren met behulp van verschillende soorten Blackbox-tests, zoals - User Acceptance Testing (UAT).

Bij Continuous Delivery wordt de applicatie continu ingezet op de testservers voor UAT. Of je kunt zeggen dat de applicatie op elk moment klaar is om voor productie te worden vrijgegeven. Het is dus duidelijk dat continue integratie noodzakelijk is voor continue levering.

Continuous Deployment is de volgende stap na Continuous Delivery, waarbij u niet alleen een implementeerbaar pakket maakt, maar het feitelijk op een geautomatiseerde manier implementeert.

Laat me de verschillen samenvatten met behulp van een tabel:

In eenvoudige bewoordingen is continue integratie een onderdeel van zowel continue levering als continue implementatie. En Continuous Deployment is als Continuous Delivery, behalve dat releases automatisch gebeuren.

Leer hoe u CI / CD-pipelines maakt met Jenkins On Cloud

Maar de vraag is of continue integratie voldoende is.

Waarom hebben we continue levering nodig?

Laten we dit begrijpen met een voorbeeld.

Stel je voor dat er 80 ontwikkelaars aan een groot project werken. Ze gebruiken Continuous Integration-pijplijnen om geautomatiseerde builds te vergemakkelijken. We weten dat build ook Unit Testing omvat. Op een dag besloten ze om de nieuwste build die de unit-tests had doorstaan ​​in een testomgeving te implementeren.

Dit moet een langdurige maar gecontroleerde benadering van de inzet zijn die hun milieuspecialisten hebben uitgevoerd. Het systeem leek echter niet te werken.

Wat zou de voor de hand liggende oorzaak van de mislukking kunnen zijn?

Welnu, de eerste reden dat de meeste mensen zullen denken, is dat er een probleem is met de configuratie. Zoals de meeste mensen dachten zelfs zij van wel.Ze hebben veel tijd besteed aan het zoeken naar wat er mis was met de configuratie van de omgeving, maar ze konden het probleem niet vinden.

Een opmerkzame ontwikkelaar koos voor een slimme aanpak:

Toen probeerde een van de senior ontwikkelaars de applicatie op zijn ontwikkelmachine. Daar werkte het ook niet.

Hij stapte terug in eerdere en eerdere versies totdat hij ontdekte dat het systeem drie weken eerder niet meer werkte. Een kleine, obscure bug had ervoor gezorgd dat het systeem niet correct kon worden opgestart. Hoewel het project een goede dekking van de unit-test had.Desondanks zagen 80 ontwikkelaars, die meestal alleen de tests uitvoerden en niet de applicatie zelf, het probleem drie weken niet.

Probleemstelling:

Zonder acceptatietests uit te voeren in een productieachtige omgeving, weten ze niets over of de applicatie voldoet aan de specificaties van de klant, noch of deze kan worden geïmplementeerd en kan overleven in de echte wereld. Als ze tijdige feedback over deze onderwerpen willen, moeten ze het bereik van hun continue integratieproces uitbreiden.

Laat me de geleerde lessen samenvatten door naar de bovenstaande problemen te kijken:

• Unit Tests testen alleen het perspectief van een ontwikkelaar op de oplossing voor een probleem. Ze hebben slechts een beperkte mogelijkheid om te bewijzen dat de applicatie doet wat hij moet doen vanuit het perspectief van de gebruiker. Ze zijn niet genoegidentificeer de echte functionele problemen.
• Het implementeren van de applicatie op de testomgeving is een complex, handmatig intensief proces dat nogal foutgevoelig was.Dit betekende dat elke poging tot implementatie een nieuw experiment was - een handmatig, foutgevoelig proces.

Oplossing - Pijplijn voor continue levering (geautomatiseerde acceptatietest):

Ze trokken Continuous Integration (Continuous Delivery) naar de volgende stap en introduceerden een aantal eenvoudige, geautomatiseerde acceptatietests die bewezen dat de applicatie draaide en zijn meest fundamentele functie kon vervullen.Het merendeel van de tests die tijdens de acceptatietestfase worden uitgevoerd, zijn functionele acceptatietests.

In feite hebben ze een Continuous Delivery-pijplijn gebouwd om ervoor te zorgen dat de applicatie naadloos wordt geïmplementeerd in de productieomgeving, door ervoor te zorgen dat de applicatie goed werkt wanneer deze wordt geïmplementeerd op de testserver die een replica is van de productieserver.

Genoeg theorie, ik zal je nu laten zien hoe je een Continuous Delivery-pijplijn kunt maken met Jenkins.

Pijplijn voor continue levering met Jenkins:

Hier zal ik Jenkins gebruiken om een ​​continue leveringspijplijn te maken, die de volgende taken omvat:

Stappen betrokken bij de demo:

• De code ophalen van GitHub
• Compileren van de broncode
• Unit testen en genereren van de JUnit-testrapporten
• Verpakken van de applicatie in een WAR-bestand en implementeren op de Tomcat-server

Voorwaarden:

• CentOS 7-machine
• Jenkins 2.121.1
• Docker
• Tomcat 7

Stap - 1 De broncode samenstellen:

Laten we beginnen met het maken van een Freestyle-project in Jenkins. Beschouw de onderstaande screenshot:

Geef uw project een naam en selecteer Freestyle Project:

Als je naar beneden scrolt, zul je een optie vinden om een ​​broncode-repository toe te voegen, git te selecteren en de repository-URL toe te voegen, in die repository is er een pom.xml-boete die we zullen gebruiken om ons project te bouwen. Beschouw de onderstaande screenshot:

Nu zullen we een Build Trigger toevoegen. Kies de poll SCM-optie, in feite zullen we Jenkins configureren om de GitHub-repository na elke 5 minuten te ondervragen voor wijzigingen in de code. Beschouw de onderstaande screenshot:

Voordat ik verder ga, wil ik u een korte inleiding geven tot de Maven Build Cycle.

Elk van de build-levenscycli wordt gedefinieerd door een andere lijst met build-fasen, waarbij een build-fase een fase in de levenscyclus vertegenwoordigt.

Hieronder volgt de lijst met bouwfasen:

• valideren - valideer dat het project correct is en dat alle benodigde informatie beschikbaar is
• compileren - compileer de broncode van het project
• test - test de gecompileerde broncode met behulp van een geschikt framework voor het testen van eenheden. Voor deze tests hoeft de code niet te worden verpakt of geïmplementeerd
• pakket - neem de gecompileerde code en verpak deze in zijn distribueerbare indeling, zoals een JAR.
• Verifiëren - voer eventuele controles uit op de resultaten van integratietests om te verzekeren dat aan de kwaliteitscriteria wordt voldaan
• install - installeer het pakket in de lokale repository, voor gebruik als afhankelijkheid in andere lokale projecten
• implementeren - gedaan in de build-omgeving, kopieert het laatste pakket naar de externe repository om te delen met andere ontwikkelaars en projecten.

Ik kan de onderstaande opdracht uitvoeren voor het compileren van de broncode, het testen van eenheden en zelfs het verpakken van de applicatie in een war-bestand:

mvn schoon pakket

U kunt uw bouwtaak ook opsplitsen in een aantal bouwstappen. Dit maakt het eenvoudiger om builds in schone, afzonderlijke fasen te organiseren.

We beginnen dus met het compileren van de broncode. Klik op het tabblad build op maven-doelen van het hoogste niveau aanroepen en typ de onderstaande opdracht:

compileren

Beschouw de onderstaande screenshot:

Dit haalt de broncode uit de GitHub-repository en compileert deze ook (Maven Compile Phase).

Klik op Opslaan en start het project.

Klik nu op de console-uitvoer om het resultaat te zien.

Stap - 2 Eenheidstest:

Nu gaan we nog een Freestyle-project maken voor het testen van eenheden.

Voeg dezelfde repository-URL toe op het tabblad Broncodebeheer, zoals we deden in de vorige taak.

Klik nu in het tabblad 'Buid Trigger' op 'bouwen nadat andere projecten zijn gebouwd'. Typ daar de naam van het vorige project waar we de broncode aan het compileren zijn, en je kunt een van de onderstaande opties selecteren:

• Trigger alleen als de build stabiel is
• Trigger zelfs als de build onstabiel is
• Trigger zelfs als de build mislukt

Ik denk dat de bovenstaande opties vrij duidelijk zijn, dus selecteer er een. Beschouw de onderstaande screenshot:

Klik op het tabblad Build op maven-doelen van het hoogste niveau aanroepen en gebruik de onderstaande opdracht:

test

Jenkins helpt u ook uitstekend bij het weergeven van uw testresultaten en trends in testresultaten.

De de facto standaard voor testrapportage in de Java-wereld is een XML-formaat dat door JUnit wordt gebruikt. Dit formaat wordt ook gebruikt door veel andere Java-testtools, zoals TestNG, Spock en Easyb. Jenkins begrijpt dit formaat, dus als uw build JUnit XML-testresultaten oplevert, kan Jenkins mooie grafische testrapporten en statistieken over testresultaten in de loop van de tijd genereren, en u ook de details van eventuele testfouten laten zien. Jenkins houdt ook bij hoe lang het duurt voordat uw tests worden uitgevoerd, zowel wereldwijd als per test. Dit kan handig zijn als u prestatieproblemen moet opsporen.

Dus het volgende dat we moeten doen, is Jenkins zover krijgen dat deze onze unit-tests in de gaten houdt.

Ga naar het gedeelte Acties na het bouwen en vink het selectievakje 'JUnit-testresultatenrapport publiceren' aan. Wanneer Maven unit-tests uitvoert in een project, genereert het automatisch de XML-testrapporten in een directory genaamd surefire-reports. Voer dus '** / target / surefire-reports / *. Xml' in het veld 'Test report XMLs' in. De twee sterretjes aan het begin van het pad ('**') zijn een best practice om de configuratie een beetje robuuster te maken: ze stellen Jenkins in staat de doelmap te vinden, ongeacht hoe we Jenkins hebben geconfigureerd om de broncode te controleren.

** / target / surefire-reports / *. xml

Sla het opnieuw op en klik op Nu bouwen.

Nu wordt het JUnit-rapport geschreven naar / var / lib / jenkins / workspace / test / gameoflife-core / target / surefire-reports / TEST-behavior.

In het Jenkins-dashboardu kunt ook de testresultaten opmerken:

Stap - 3 Een WAR-bestand maken en implementeren op de Tomcat-server:

Nu is de volgende stap om onze applicatie in een WAR-bestand te verpakken en dat op de Tomcat-server te implementeren voor de test voor gebruikersacceptatie.

Maak nog een freestyle-project en voeg de broncode-repository-URL toe.

Selecteer vervolgens op het tabblad buildtrigger build wanneer andere projecten worden gebouwd, bekijk de onderstaande schermafbeelding:

Kortom, na de testtaak begint de implementatiefase automatisch.

Selecteer shellscript op het tabblad build. Typ de onderstaande opdracht om de toepassing in een WAR-bestand te verpakken:

mvn-pakket

De volgende stap is om dit WAR-bestand op de Tomcat te implementerenserver. Selecteer op het tabblad 'Post-Build Actions' de optie War / Ear inzetten in een container. Geef hier het pad naar het WAR-bestand en geef het contextpad op. Beschouw de onderstaande screenshot:

Selecteer de Tomcat-inloggegevens en let op de bovenstaande schermafbeelding. U moet ook de URL van uw Tomcat-server opgeven.

Om inloggegevens toe te voegen in Jenkins, klikt u op de optie inloggegevens op het Jenkins-dashboard.

Klik op Systeem en selecteer algemene inloggegevens.

Vervolgens vindt u een optie om de inloggegevens toe te voegen. Klik erop en voeg inloggegevens toe.

Voeg de Tomcat-inloggegevens toe, bekijk de onderstaande schermafbeelding.

wat is pojo-klasse in java met voorbeeld

Klik op OK.

Voeg nu in uw projectconfiguratie de tomcat-inloggegevens toe die u in de vorige stap hebt ingevoerd.

Klik op Opslaan en selecteer vervolgens Nu bouwen.

Ga naar je tomcat-URL, met het contextpad, in mijn geval is dit http: // localhost: 8081. Voeg nu het contextpad aan het einde toe, overweeg de onderstaande Screenshot:

Link - http: // localhost: 8081 / gof

Ik hoop dat je de betekenis van het contextpad hebt begrepen.

Maak nu een pijplijnweergave, bekijk de onderstaande schermafbeelding:

Klik op het pluspictogram om een ​​nieuwe weergave te maken.

Configureer de pijplijn zoals u dat wilt, bekijk de onderstaande schermafbeelding:

Ik heb niets veranderd behalve het selecteren van de eerste baan. Dus mijn pijplijn begint bij het compileren. Op basis van de manier waarop ik andere taken heb geconfigureerd, zullen na het compileren testen en implementeren plaatsvinden.

Ten slotte kunt u de pijplijn testen door op UITVOEREN te klikken. Als er na elke vijf minuten een wijziging in de broncode is, wordt de hele pijplijn uitgevoerd.

We zijn dus in staat om onze applicatie continu op de testserver in te zetten voor gebruikersacceptatietest (UAT).

Ik hoop dat je dit bericht met veel plezier hebt gelezen over Continuous Delivery. Als u twijfels heeft, kunt u deze in de commentaarsectie hieronder plaatsen en ik zal op zijn vroegst terugkomen met een antwoord.

Om CI / CD-pijpleidingen te bouwen, moet u een grote verscheidenheid aan vaardigheden beheersen Beheers nu de vereiste DevOps-vaardigheden