Er waren tijden dat we Jenkins-taken alleen via de gebruikersinterface maakten. Later werd het idee van pipeline als code ingevoerd om de toenemende complexiteit van build- en implementatietaken aan te pakken. In Jenkins 2.0 introduceerde het Jenkins-team Jenkinsfile om pipeline als code te realiseren. Als je een geautomatiseerde pull request-gebaseerde of branch-gebaseerde Jenkins Continue Integratie en Continue Levering pipeline wilt maken, is de Jenkins multibranch pipeline de manier om te gaan.
Omdat de Jenkins multi-branch pipeline volledig op git gebaseerd is, kun je je CI/CD-werkstromen opzetten. Pipeline as Code (PaaC) maakt het gemakkelijk om de voordelen van automatisering en cloud-portabiliteit te bieden voor je Selenium. Je kunt het multi-branch pipeline-model gebruiken om snel en betrouwbaar je Selenium-tests te bouwen, testen, implementeren, monitoren, rapporteren en beheren, en nog veel meer. In deze Jenkins-tutorial bekijken we hoe je een Jenkins multibranch pipeline kunt maken en de belangrijkste concepten die betrokken zijn bij het configureren van een Jenkins multibranch pipeline voor Selenium automatiseringstesten.
Laten we beginnen.
Wat Is Jenkins Multibranch Pipeline?
Volgens de officiële documentatie is een multibranch pipeline-taaktype een taak waarbij vanuit een enkele git-repository Jenkins meerdere branches detecteert en geneste taken maakt wanneer het een Jenkinsfile vindt.
Uit bovenstaande definitie kunnen we begrijpen dat Jenkins Git-repo’s kan scannen op Jenkinsfile en taken automatisch kan aanmaken. Het enige dat het van ons nodig heeft, zijn de details van de Git-Repo. In dit artikel gaan we gebruik maken van een voorbeeld GitHub-repository. Onze voorbeeld GitHub-repo bevat een voorbeeld Spring Boot-project, dat kan worden geïmplementeerd op Tomcat.
In de hoofdmap van het project hebben we de Jenkinsfile. We hebben de Jenkins Declarative pipeline-syntax gebruikt om deze Jenkinsfile te maken. Als je nieuw bent in Jenkins Declarative pipeline, lees dan ons gedetailleerde artikel hier.
Voorbeeld Jenkinsfile
pipeline {
agent any
stages {
stage('Build Code') {
steps {
sh """
echo "Building Artifact"
"""
}
}
stage('Deploy Code') {
steps {
sh """
echo "Deploying Code"
"""
}
}
}
}We hebben twee stadia “Bouw Code” en “Implementeer Code” in onze Jenkinsfile gemaakt, elk ervan geconfigureerd om passende berichten af te drukken. Nu hebben we de Git-repo met Jenkinsfile klaar.
Laten we een Jenkins multibranch pipeline aanmaken op de Jenkins-server.
Jenkins Pipeline vs Multibranch Pipeline
Jenkins pipeline is het nieuwe heetst, maar het is niet voor iedereen. En multibranch pipelines zijn nog steeds geweldig. In deze sectie van de Jenkins multibranch pipeline tutorial, laten we de ideale gebruiksgevallen voor Jenkins pipeline en multibranch pipeline begrijpen door middel van deze Jenkins pipeline vs multibranch pipeline vergelijking.
Jenkins pipeline is een jobconfiguratiesysteem dat ervoor zorgt dat je een pijplijn van taken kunt configureren, die automatisch voor jou worden uitgevoerd. Een Jenkins pipeline kan meerdere stadia hebben en elk stadium wordt uitgevoerd door een enkele agent, allemaal draaiend op één of meerdere machines. Een pijplijn wordt normaal gesproken gemaakt voor een specifieke branch van broncode. Wanneer je een nieuwe taak maakt, zie je een optie voor het selecteren van de broncode-repository en branch. Je kunt ook een nieuwe pijplijn maken voor een nieuw project of een nieuw kenmerk van een bestaand project.
Jenkins pipeline stelt je in staat om een flexibele Jenkinsfile te hebben met stadia voor je build. Zo kun je een eerste stadium hebben waar je linting, tests, enz. uitvoert, en vervolgens afzonderlijke stadia voor het bouwen van artefacten of het implementeren ervan. Dit is erg handig wanneer je meerdere dingen in je pijplijn wilt doen.
Wat als je maar één ding moet doen? Of als alle dingen die je wilt doen verschillen afhankelijk van een bepaalde configuratie? Maakt het dan nog zin om Jenkins pipeline te gebruiken?
De multibranch pipeline is een alternatieve aanpak die misschien beter geschikt is in deze gevallen. De multibranch pipeline stelt je in staat om taken uit te splitsen in branches en ze later samen te voegen. Dit lijkt erg op de manier waarop Git branching werkt.
A multibranch pipeline is a pipeline that has multiple branches. The main advantage of using a multibranch pipeline is to build and deploy multiple branches from a single repository. Having a multibranch pipeline also allows you to have different environments for different branches. However, it is not recommended to use a multibranch pipeline if you do not have a standard branching and CI/CD strategy.
Nu je de vergelijking tussen Jenkins pipeline en multibranch pipeline hebt gezien, laten we de stappen doorlopen om een Jenkins multibranch pipeline te maken.
Maken van een Jenkins Multibranch Pipeline
Stap 1
Open de Jenkins startpagina (http://localhost:8080 in lokale omgeving) en klik op ” Nieuw Item ” in het menu aan de linkerkant.
Stap 2
Voer naam van Jenkins-taak in, kies de stijl als “multibranch pipeline,” en klik op “OK.”
Stap 3
Op de “Configureren” pagina, moeten we slechts één ding configureren: De Git Repo bron.
Scroll naar beneden naar het “Branch Bronnen” gedeelte en klik op de “Bron Toevoegen” dropdown.
Kies “GitHub” als bron omdat onze voorbeeld-GitHub-repo daar gehost wordt.
Stap 4
Voer de Repository HTTPS URL in als https://github.com/iamvickyav/spring-boot-h2-war-tomcat.git en klik op “Valideren.”
Omdat onze GitHub-repo als publieke repo gehost wordt, hoeven we geen referenties te configureren om toegang te krijgen. Voor bedrijf/privé-repos, kunnen we referenties nodig hebben om toegang te krijgen.
De “Referenties ok” boodschap vertegenwoordigt de succesvolle verbinding tussen Jenkins-server en de Git-repo.
Stap 5
Laat de rest van de configuratie secties voorlopig zoals ze zijn en klik op de “Opslaan” knop onderaan.
Bij het opslaan zullen de volgende stappen automatisch door Jenkins worden uitgevoerd:
Scan Repository Step
- Scan de geconfigureerde Git-repo.
- Zoek de lijst van beschikbare branches in de Git-repo.
- Selecteer de branches die een Jenkinsfile hebben.
Running Build Step
- Voer de build uit voor elk van de branches die zijn gevonden in de vorige stap met de stappen die worden genoemd in de Jenkinsfile.
Uit de sectie “Scan Repository Log” kunnen we begrijpen wat er gebeurde tijdens de Scan repository stap.
Omdat we slechts een master branch in onze git-repo hebben, zegt de Scan Repository Log “1 branches werden verwerkt.”
Na voltooiing van de scan zal Jenkins een build-taak maken en uitvoeren voor elke apart verwerkte branch.
In ons geval hadden we slechts één branch genaamd master. Daarom zal de build alleen voor onze master branch worden uitgevoerd. We kunnen dit controleren door op “Status” in het linkerzijmenu te klikken.
We kunnen een build-taak voor de master branch zien in de statussectie.
Klik op de branchnaam om de build-taaklog en status te zien.
“Stage View” geeft een visuele weergave van hoeveel tijd elke fase kostte om uit te voeren en de status van de build-taak.
Toegang tot Build Job Run Logs
Stap 1
Klik op de “Build nummer” onder de “Buildgeschiedenis” sectie.
Stap 2
Kies vervolgens de “Console Output” uit het linkerzijmenu om de logs te zien.
Wat gebeurt er als we meer dan één branch in onze Git-repo hebben? Laten we dat nu controleren.
In de Git-repo wordt een nieuwe branch genaamd “develop” aangemaakt.
Om de “ontwikkel” branch build te onderscheiden, hebben we kleine wijzigingen aangebracht in echo-opdrachten in Jenkinsfile.
Jenkinsfile in Master Branch
pipeline {
agent any
stages {
stage('Build Code') {
steps {
sh """
echo "Building Artifact"
"""
}
}
stage('Deploy Code') {
steps {
sh """
echo "Deploying Code"
"""
}
}
}
}Jenkinsfile in Develop Branch
pipeline {
agent any
stages {
stage('Build Code') {
steps {
sh """
echo "Building Artifact from Develop Branch"
"""
}
}
stage('Deploy Code') {
steps {
sh """
echo "Deploying Code from Develop Branch"
"""
}
}
}
}Nu hebben we twee Jenkinsfile in twee verschillende branches. Laten we de repository scan in Jenkins opnieuw uitvoeren om het gedrag te zien.
We kunnen zien dat de nieuwe branch (develop branch) door Jenkins gedetecteerd is. Daarom is er een nieuwe taak gecreëerd voor de develop branch.
Door op “ontwikkel” te klikken, kunnen we de log voor de buildtaak van de develop branch zien.
In het vorige voorbeeld hielden we verschillende inhoud voor Jenkinsfile in de master en develop branches. Maar dat is niet hoe we dat in echte toepassingen doen. We gebruiken de when blokken binnen stage blok om de branch te controleren.
Hier is een voorbeeld met gecombineerde stappen voor de master en develop branches. Dezezelfde inhoud wordt in beide master en develop branch Jenkinsfiles geplaatst.
pipeline {
agent any
stages {
stage('Master Branch Deploy Code') {
when {
branch 'master'
}
steps {
sh """
echo "Building Artifact from Master branch"
"""
sh """
echo "Deploying Code from Master branch"
"""
}
}
stage('Develop Branch Deploy Code') {
when {
branch 'develop'
}
steps {
sh """
echo "Building Artifact from Develop branch"
"""
sh """
echo "Deploying Code from Develop branch"
"""
}
}
}
}Stap 3
Klik op “Scan Repository” vanaf het linkerzijmenu om Jenkins de nieuwe wijzigingen vanuit Git repo te laten detecteren.
Tegen deze tijd had je misschien gemerkt dat we de scan repository gebruiken elke keer dat we willen dat Jenkins de wijzigingen vanuit de repo detecteert.
Hoe zit het met het automatiseren van deze stap?
Periodieke Trigger voor Jenkins Multibranch Pipeline Scan
Stap 1
Klik op “Configureren” vanaf het linkerzijmenu.
Stap 2
Scrol naar het “Scan Repository Triggers” gedeelte en schakel het selectievakje “Periodiek als het niet anderszins wordt uitgevoerd” in en kies het tijdsinterval voor de periodieke scan (twee minuten in ons voorbeeld).
Stap 3
Klik op de knop “Opslaan“.
Vanaf nu zal Jenkins elke twee minuten de repo scannen. Als er een nieuwe commit wordt gevonden in een willekeurige branch, zal Jenkins een nieuwe build job voor die specifieke branch uitvoeren met behulp van Jenkinsfile.
Hieronder staat de “Scan Repository Log“, die duidelijk aangeeft dat de scan elke twee minuten wordt geactiveerd.
Echte gebruiksvoorbeelden voor Jenkins Multibranch Pipeline
Hieronder staan enkele scenario’s waarin de Jenkins multibranch pipeline handig kan zijn:
- Elke nieuwe commit in de master branch moet automatisch op de server worden geïmplementeerd.
- Als een ontwikkelaar probeert een Pull Request (PR) in te dienen voor de ontwikkelingsbranch, moet het volgende gebeuren:
- De code moet succesvol worden gebouwd zonder compilatiefout.
- De code moet minimaal 80% testdekking hebben.
- De code moet de SONAR-codekwaliteitstest doorstaan.
- Als ontwikkelaars proberen code naar een branch te pushen die niet master of ontwikkel is, moet de code succesvol compileren. Zo niet, stuur een waarschuwingsmail.
Hier is een voorbeeld Jenkinsfile die enkele van de bovenstaande gebruiksvoorbeelden behandelt:
pipeline {
agent any
tools {
maven 'MAVEN_PATH'
jdk 'jdk8'
}
stages {
stage("Tools initialization") {
steps {
sh "mvn --version"
sh "java -version"
}
}
stage("Checkout Code") {
steps {
checkout scm
}
}
stage("Check Code Health") {
when {
not {
anyOf {
branch 'master';
branch 'develop'
}
}
}
steps {
sh "mvn clean compile"
}
}
stage("Run Test cases") {
when {
branch 'develop';
}
steps {
sh "mvn clean test"
}
}
stage("Check Code coverage") {
when {
branch 'develop'
}
steps {
jacoco(
execPattern: '**/target/**.exec',
classPattern: '**/target/classes',
sourcePattern: '**/src',
inclusionPattern: 'com/iamvickyav/**',
changeBuildStatus: true,
minimumInstructionCoverage: '30',
maximumInstructionCoverage: '80')
}
}
stage("Build and Deploy Code") {
when {
branch 'master'
}
steps {
sh "mvn tomcat7:deploy"
}
}
}
}We hebben deze nieuwe Jenkinsfile in de master- en ontwikkelingsbranches gepusht, zodat deze kan worden gedetecteerd door de Jenkins multibranch bij de volgende repositoryscan.
Selenium Automation Testing With Jenkins Multibranch Pipeline
Laten we aannemen dat we automatiseringstestgevallen schrijven voor een website. Telkens wanneer er een nieuw testgeval in een branch wordt gepusht, willen we deze uitvoeren en ervoor zorgen dat ze zoals verwacht werken.
Het uitvoeren van automatiseringstestgevallen op elke combinatie van browser en besturingssysteem is een nachtmerrie voor elke ontwikkelaar. Daar kan de krachtige automatiseringstestinfrastructuur van LambdaTest van pas komen.
Met de LambdaTest Selenium grid kunt u uw browserdekking maximaliseren.
In deze sectie zullen we zien hoe we de testinfrastructuur van LambdaTest kunnen benutten met de Jenkins multibranch pipeline. Ter demonstratie hebben we hier een voorbeeld-Todo-app gehost – LambdaTest ToDo App. Automatiseringstestgevallen geschreven met Cucumber zijn in de voorbeeld-repo gepusht.
Vanuit Jenkins willen we deze testgevallen uitvoeren op het LambdaTest platform. Het uitvoeren van testgevallen op LambdaTest vereist een gebruikersnaam en een accessToken. Registreer je gratis bij het LambdaTest platform om je referenties te krijgen.
Instellen van Omgevingsvariabelen
Wanneer het testgeval wordt uitgevoerd, zal het op zoek gaan naar de gebruikersnaam (LT_USERNAME) en het wachtwoord (LT_ACCESS_KEY) van LambdaTest in omgevingsvariabelen. Daarom moeten we deze vooraf configureren.
Om te voorkomen dat ze worden opgeslagen met de broncode, hebben we ze als geheimen in Jenkins geconfigureerd en omgevingsvariabelen vanuit hen geladen:
environment {
LAMBDATEST_CRED = credentials('Lambda-Test-Credentials-For-multibranch')
LT_USERNAME = "$LAMBDATEST_CRED_USR"
LT_ACCESS_KEY = "$LAMBDATEST_CRED_PSW"
}Hier is onze uiteindelijke Jenkinsfile:
pipeline {
agent any
tools {
maven 'MAVEN_PATH'
jdk 'jdk8'
}
stages {
stage("Tools initialization") {
steps {
sh "mvn --version"
sh "java -version"
}
}
stage("Checkout Code") {
steps {
checkout scm
}
}
stage("Check Code Health") {
when {
not {
anyOf {
branch 'master';
branch 'develop'
}
}
}
steps {
sh "mvn clean compile"
}
}
stage("Run Test cases in LambdaTest") {
when {
branch 'develop';
}
environment {
LAMBDATEST_CRED = credentials('Lambda-Test-Credentials-For-multibranch')
LT_USERNAME = "$LAMBDATEST_CRED_USR"
LT_ACCESS_KEY = "$LAMBDATEST_CRED_PSW"
}
steps {
sh "mvn test"
}
}
}
}Nu gaan we een nieuwe “Job” in Jenkins maken als een multibranch-pijplijn door de stappen te volgen die in de bovenstaande secties zijn genoemd. Laten we naar de voorbeeld-repo verwijzen.
Zodra de build succesvol is uitgevoerd, bezoek de LambdaTest automatisering dashboard om de testlogboeken te bekijken.
Conclusie
Hiermee hebben we geleerd hoe we een Jenkins multibranch-pijplijn kunnen maken, hoe we een git-repo erin kunnen configureren, verschillende buildstappen voor verschillende branches, het gebruik van periodieke autoscan van de repo door Jenkins en het inzetten van de krachtige automatiseringstestinfrastructuur van LambdaTest om onze CI/CD-builds te automatiseren. Ik hoop dat u dit artikel nuttig vond. Gelieve uw feedback in de commentaarsectie te delen.
Source:
https://dzone.com/articles/how-to-create-jenkins-multibranch-pipeline