Il y a eu des moments où nous créions des tâches Jenkins en utilisant uniquement l’interface utilisateur. Plus tard, l’idée de pipeline en tant que code a été évoquée pour faire face à la complexité croissante des tâches de construction et de déploiement. Dans Jenkins 2.0, l’équipe Jenkins a introduit Jenkinsfile pour réaliser le pipeline en tant que code. Si vous souhaitez créer un pipeline Jenkins automatisé basé sur la demande de tirage ou basé sur les branches pour l’Intégration Continue et Livraison Continue, le pipeline multibranche Jenkins est la solution à adopter.
Comme le pipeline multibranche Jenkins est entièrement basé sur git en tant que code de pipeline, vous pouvez construire vos workflows CI/CD. Le Pipeline en tant que Code (PaaC) facilite l’ajout des avantages de l’automatisation et de la portabilité cloud à votre Selenium. Vous pouvez utiliser le modèle de pipeline multibranche pour construire rapidement et de manière fiable, tester, déployer, surveiller, signaler et gérer vos tests Selenium, et bien plus encore. Dans ce tutoriel Jenkins, nous examinons comment créer un pipeline multibranche Jenkins et les concepts clés impliqués dans la configuration d’un pipeline multibranche Jenkins pour les tests d’automatisation Selenium.
C’est parti.
Qu’est-ce qu’un Pipeline Multibranche Jenkins?
Selon la documentation officielle, un type de travail de pipeline multibranche vous permet de définir un travail à partir d’un seul dépôt git, Jenkins détectera plusieurs branches et créera des travaux imbriqués lorsqu’il trouvera un Jenkinsfile.
D’après la définition ci-dessus, nous pouvons comprendre que Jenkins peut scanner un dépôt Git pour rechercher un Jenkinsfile et créer des tâches automatiquement. Tout ce dont il a besoin de notre part, ce sont les détails du dépôt Git. Dans cet article, nous allons utiliser un exemple de dépôt GitHub. Notre exemple de dépôt GitHub contient un projet Spring Boot de démonstration, qui peut être déployé sur Tomcat.
Dans le répertoire racine du projet, nous avons le Jenkinsfile. Nous avons utilisé la syntaxe de pipeline déclarative Jenkins pour créer ce Jenkinsfile. Si vous êtes nouveau sur le pipeline déclarative Jenkins, veuillez lire notre article détaillé ici.
Exemple de Jenkinsfile
pipeline {
agent any
stages {
stage('Build Code') {
steps {
sh """
echo "Building Artifact"
"""
}
}
stage('Deploy Code') {
steps {
sh """
echo "Deploying Code"
"""
}
}
}
}Nous avons créé deux étapes « Construire le code » et « Déployer le code » dans notre Jenkinsfile, chacune d’entre elles configurée pour imprimer des messages appropriés. Maintenant, nous avons le dépôt Git avec Jenkinsfile prêt.
Créons un pipeline multibranche Jenkins sur le serveur Jenkins.
Pipeline Jenkins vs Pipeline Multibranche
Le pipeline Jenkins est la nouveauté en vogue, mais il ne convient pas à tout le monde. Et les pipelines multibranches sont toujours géniaux. Dans cette section du tutoriel sur le pipeline multibranche Jenkins, comprenons les cas d’utilisation idéaux pour le pipeline Jenkins et le pipeline multibranche à travers cette comparaison entre pipeline Jenkins et pipeline multibranche.
Jenkins pipeline est un système de configuration de travaux qui vous permet de configurer un pipeline de travaux, qui seront exécutés automatiquement pour vous. Un pipeline Jenkins peut avoir plusieurs étapes et chaque étape sera exécutée par un seul agent, tous fonctionnant sur un seul ordinateur ou plusieurs ordinateurs. Un pipeline est normalement créé pour une branche spécifique de code source. Lorsque vous créez un nouveau travail, vous verrez une option pour sélectionner le dépôt de code source et la branche. Vous pouvez également créer un pipeline frais pour un nouveau projet ou une nouvelle fonctionnalité d’un projet existant.
Jenkins pipeline vous permet d’avoir un Jenkinsfile flexible avec des étapes pour votre build. Ainsi, vous pouvez avoir une étape initiale où vous exécutez le linting, les tests, etc., puis des étapes séparées pour la construction des artefacts ou leur déploiement. Ceci est très utile lorsque vous souhaitez effectuer plusieurs choses dans votre pipeline.
Et si vous n’avez qu’une seule chose à faire ? Ou si toutes les choses que vous souhaitez faire sont différentes en fonction de certaines configurations ? Cela a-t-il du sens d’utiliser Jenkins pipeline ici ?
Le pipeline multibranche est une approche alternative qui pourrait être plus appropriée dans ces cas. Le pipeline multibranche vous permet de diviser les tâches en branches et de les fusionner plus tard. Ceci est très similaire à la manière dont fonctionne la branche Git.
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.
Maintenant, puisque vous avez vu la comparaison entre Jenkins pipeline et multibranch pipeline, passons par les étapes pour créer un pipeline multibranche Jenkins.
Création d’un Pipeline Multibranche Jenkins
Étape 1
Ouvrez la page d’accueil Jenkins (http://localhost:8080 localement) et cliquez sur « Nouvel élément » dans le menu de gauche.
Étape 2
Saisissez nom du travail Jenkins, choisissez le style comme “pipeline multibranche,” et cliquez sur “OK.”
Étape 3
Sur la page “Configurer”, nous avons besoin de configurer une seule chose: La source du dépôt Git.
Faites défiler jusqu’à la section “Sources de Branches” et cliquez sur le menu déroulant “Ajouter une Source”.
Choisissez “GitHub” comme source car notre exemple de dépôt GitHub est hébergé là-bas.
Étape 4
Saisissez l’URL HTTPS du dépôt comme https://github.com/iamvickyav/spring-boot-h2-war-tomcat.git et cliquez sur “Valider.”
Puisque notre dépôt GitHub est hébergé en tant que dépôt public, nous n’avons pas besoin de configurer d’identifiants pour y accéder. Pour les dépôts privés/entreprise, nous pourrions avoir besoin d’identifiants pour y accéder.
Le message “Identifiants OK” représente le succès de la connexion entre le serveur Jenkins et le dépôt Git.
Étape 5
Laissez le reste des sections de configuration telles quelles pour l’instant et cliquez sur le bouton “Enregistrer” en bas.
En enregistrant, Jenkins effectuera automatiquement les étapes suivantes:
Étape de Scan du Dépôt
- Scannez le dépôt Git que nous avons configuré.
- Recherchez la liste des branches disponibles dans le dépôt Git.
- Sélectionnez les branches qui ont Jenkinsfile.
Étape de Construction en Cours
- Exécutez la construction pour chacune des branches trouvées à l’étape précédente avec les étapes mentionnées dans le Jenkinsfile.
À partir de la section “Examen du journal du dépôt”, nous pouvons comprendre ce qui s’est passé lors de l’étape d’examen du dépôt.
Puisque nous n’avons qu’une branche principale dans notre dépôt git, le journal d’examen du dépôt indique “1 branches ont été traitées.”
Une fois l’examen terminé, Jenkins créera et exécutera un travail de construction pour chaque branche traitée séparément.
Dans notre cas, nous avions une seule branche appelée master. Par conséquent, la construction sera exécutée uniquement pour notre branche principale. Nous pouvons vérifier cela en cliquant sur “Statut” dans le menu de gauche.
Nous pouvons voir un travail de construction créé pour la branche principale dans la section Statut.
Cliquez sur le nom de la branche pour voir le journal et le statut du travail de construction.
“Vue des étapes” donne une représentation visuelle du temps nécessaire à l’exécution de chaque étape et du statut du travail de construction.
Accéder aux journaux d’exécution du travail de construction
Étape 1
Cliquez sur le “numéro de build” sous la section “Historique des builds”.
Étape 2
Ensuite, choisissez le “Sortie de la console” dans le menu de gauche pour voir les journaux.
Que se passe-t-il si nous avons plus d’une branche dans notre dépôt Git? Vérifions cela maintenant.
Dans le dépôt Git, une nouvelle branche appelée “développement” est créée.
Pour différencier la build de la branche « développer« , nous avons apporté de petites modifications dans les commandes echo dans le Jenkinsfile.
Jenkinsfile dans la Branche Master
pipeline {
agent any
stages {
stage('Build Code') {
steps {
sh """
echo "Building Artifact"
"""
}
}
stage('Deploy Code') {
steps {
sh """
echo "Deploying Code"
"""
}
}
}
}Jenkinsfile dans la Branche Développement
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"
"""
}
}
}
}Maintenant, nous avons deux Jenkinsfile dans deux branches différentes. Réexécutons l’analyse du dépôt dans Jenkins pour observer le comportement.
Nous pouvons constater que la nouvelle branche (branche de développement) a été détectée par Jenkins. Par conséquent, un nouveau travail a été créé séparément pour la branche de développement.
En cliquant sur « développement« , nous pouvons voir le journal de la build de la branche de développement.
Dans l’exemple précédent, nous avons conservé des contenus différents pour le Jenkinsfile dans les branches master et développement. Mais ce n’est pas comme cela que nous procédons dans les applications du monde réel. Nous utilisons les blocs when à l’intérieur du bloc stage pour vérifier la branche.
Voici un exemple avec des étapes combinées pour les branches master et développement. Ce même contenu sera placé dans les deux Jenkinsfiles des branches master et développement.
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"
"""
}
}
}
}Étape 3
Cliquez sur « Scanner le dépôt » dans le menu de gauche pour que Jenkins détecte les nouvelles modifications du dépôt Git.
À ce stade, vous auriez pu remarquer que nous utilisons l’analyse du dépôt chaque fois que nous voulons que Jenkins détecte les changements du dépôt.
Et si nous automatisions cette étape ?
Déclencheur périodique pour l’analyse de Pipeline Multibranche Jenkins
Étape 1
Cliquez sur « Configurer » dans le menu de gauche.
Étape 2
Faites défiler jusqu’à la section « Déclencheurs de balayage du dépôt » et activez la case à cocher « Périodiquement si pas autrement exécuté » et choisissez l’intervalle de temps pour que le balayage s’exécute périodiquement (deux minutes dans notre exemple).
Étape 3
Cliquez sur le bouton « Enregistrer« .
À partir de maintenant, Jenkins balaiera le dépôt toutes les deux minutes. Si un nouveau commit est détecté dans n’importe quelle branche, Jenkins exécutera un nouveau job de build pour cette branche spécifique en utilisant Jenkinsfile.
Voici le « Journal de balayage du dépôt« , qui montre clairement le déclenchement du balayage toutes les deux minutes.
Cas d’utilisation en temps réel pour Jenkins Multibranch Pipeline
Voici quelques scénarios où Jenkins multibranch pipeline peut être pratique:
- Tout nouveau commit dans la branche principale doit être déployé sur le serveur automatiquement.
- Si un développeur tente de soumettre une Pull Request (PR) pour développer une branche, alors:
- Le code doit être construit avec succès sans erreur de compilation.
- Le code doit avoir une couverture de test d’au moins 80%.
- Le code doit passer le test de qualité du code SONAR.
- Si les développeurs tentent de pousser le code dans une branche autre que master ou develop, le code doit compiler avec succès. Sinon, envoyer un e-mail d’alerte.
Voici un exemple de Jenkinsfile couvrant quelques-uns des cas d’utilisation ci-dessus:
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"
}
}
}
}Nous avons intégré ce nouveau Jenkinsfile dans les branches master et develop, afin qu’il soit détecté par le multibranch Jenkins lors de la prochaine analyse du dépôt.
Tests d’automatisation Selenium avec Pipeline Multibranch Jenkins
Supposons que nous écrivions des cas de test d’automatisation pour un site web. Chaque fois qu’un nouveau cas de test est commit dans une branche, nous voulons les exécuter et nous assurer qu’ils s’exécutent comme prévu.
Exécuter des cas de test d’automatisation sur chaque combinaison de navigateur et système d’exploitation est un cauchemar pour tout développeur. C’est là que l’infrastructure puissante de tests d’automatisation de LambdaTest peut s’avérer précieuse.
En utilisant le grille Selenium de LambdaTest, vous pouvez maximiser votre couverture de navigateur.
Dans cette section, nous allons voir comment tirer parti de l’infrastructure de test de LambdaTest avec le pipeline multibranch Jenkins. Pour illustrer cela, nous avons hébergé une application Todo d’exemple ici – Application Todo LambdaTest. Des cas de test d’automatisation écrits avec Cucumber sont commit dans le dépôt d’exemple.
À partir de Jenkins, nous voulons exécuter ces cas de test sur la plateforme LambdaTest. L’exécution de cas de test sur LambdaTest nécessite un nom d’utilisateur et un accessToken. Inscrivez-vous gratuitement sur la plateforme LambdaTest pour obtenir vos identifiants.
Configuration de la Variable d’Environnement
Lorsque le cas de test s’exécute, il recherchera le nom d’utilisateur (LT_USERNAME) et le mot de passe (LT_ACCESS_KEY) de LambdaTest dans les variables d’environnement. Par conséquent, nous devons les configurer à l’avance.
Pour éviter de les stocker avec le code source, nous les avons configurés en tant que secrets dans Jenkins et chargé les variables d’environnement à partir d’eux:
environment {
LAMBDATEST_CRED = credentials('Lambda-Test-Credentials-For-multibranch')
LT_USERNAME = "$LAMBDATEST_CRED_USR"
LT_ACCESS_KEY = "$LAMBDATEST_CRED_PSW"
}Voici notre Jenkinsfile final:
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"
}
}
}
}Maintenant, nous allons créer un nouveau « Job » dans Jenkins en tant que pipeline multibranche en suivant les étapes mentionnées dans les sections ci-dessus. Pointons vers le dépôt d’exemple.
Une fois que la build réussit, visitez le tableau de bord de l’automatisation LambdaTest pour obtenir les journaux des tests.
Conclusion
Avec cela, nous avons appris à créer un pipeline multibranche Jenkins, à configurer un dépôt git en son sein, à utiliser différentes étapes de build pour différentes branches, à utiliser l’autoscan périodique du dépôt par Jenkins et à tirer parti de l’infrastructure puissante d’automatisation de tests de LambdaTest pour automatiser nos builds CI/CD. J’espère que cet article vous a été utile. Veuillez partager vos commentaires dans la section des commentaires.
Source:
https://dzone.com/articles/how-to-create-jenkins-multibranch-pipeline