Il y avait des moments où nous avions l’habitude de créer des emplois Jenkins en utilisant uniquement l’interface utilisateur. Plus tard, l’idée du pipeline en tant que code a été évoquée pour répondre à 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 d’intégration continue et de livraison continue Jenkins basé sur des demandes d’extraction automatisées ou basé sur des branches, le pipeline multibranche Jenkins est une solution.
Comme le pipeline multi-branches Jenkins est entièrement un pipeline basé sur git en tant que code, vous pouvez créer vos workflows CI/CD. Pipeline as Code (PaaC) permet d’apporter facilement les avantages de l’automatisation et de la portabilité cloud à votre Selenium. Vous pouvez utiliser le modèle de pipeline multi-branches pour créer, tester, déployer, surveiller, créer des rapports et gérer rapidement et de manière fiable vos tests Selenium, et bien plus encore. Dans ce didacticiel 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.
Commençons.
Qu’est-ce que le pipeline multibranche Jenkins ?
Selon la documentation officielle, un type de travail de pipeline multibranche vous permet de définir un travail où, à partir d’un seul référentiel git, Jenkins détectera plusieurs branches et créera des travaux imbriqués lorsqu’il trouvera un fichier Jenkins.
D’après la définition ci-dessus, nous pouvons comprendre que Jenkins peut analyser le référentiel Git pour Jenkinsfile et créer des tâches automatiquement. Tout ce dont nous avons besoin, ce sont les détails de Git Repo. Dans cet article, nous allons utiliser un exemple de référentiel GitHub. Notre exemple de référentiel GitHub contient un exemple de projet Spring Boot, 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 Jenkins Declarative pour créer ce fichier Jenkins. Si vous êtes nouveau dans le pipeline déclaratif Jenkins, veuillez lire notre article détaillé ici.
Exemple de fichier Jenkins
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 « Build Code » et « Deploy Code » dans notre fichier Jenkins, chacune configurée pour imprimer les messages appropriés. Maintenant, nous avons le référentiel Git avec Jenkinsfile prêt.
Créons un pipeline multibranche Jenkins dans le serveur Jenkins.
Pipeline Jenkins vs Pipeline multibranche
Le pipeline Jenkins est la nouvelle tendance, mais ce n’est pas pour tout le monde. Et les pipelines multibranches sont toujours géniaux. Dans cette section du didacticiel sur le pipeline multibranche Jenkins, comprenons les cas d’utilisation idéaux pour le pipeline Jenkins et le pipeline multibranche grâce à cette comparaison entre pipeline Jenkins et pipeline multibranche.
Le pipeline Jenkins est un système de configuration de tâches qui vous permet de configurer un pipeline de tâches, qui seront exécutées automatiquement en votre nom. Un pipeline Jenkins peut avoir plusieurs étapes et chaque étape sera exécutée par un seul agent, le tout s’exécutant sur une ou plusieurs machines. Un pipeline est normalement créé pour une branche spécifique du code source. Lorsque vous créez un nouveau travail, vous verrez une option pour sélectionner le référentiel de code source et la branche. Vous pouvez également créer un nouveau pipeline pour un nouveau projet ou une nouvelle fonctionnalité d’un projet existant.
Le pipeline Jenkins vous permet d’avoir un fichier Jenkins flexible avec des étapes pour votre build. Ainsi, vous pouvez avoir une étape initiale où vous exécutez des peluches, des tests, etc., puis des étapes séparées pour créer des artefacts ou les déployer. Ceci est très utile lorsque vous souhaitez faire plusieurs choses dans votre pipeline.
Et si vous n’aviez qu’une chose à faire ? Ou si toutes les choses que vous voulez faire sont différentes selon certaines configurations ? Est-il judicieux d’utiliser le pipeline Jenkins 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 au fonctionnement de la création de branches Git.
Un pipeline multibranche est un pipeline qui a plusieurs branches. Le principal avantage de l’utilisation d’un pipeline multibranche est de créer et de déployer plusieurs branches à partir d’un seul référentiel. Avoir un pipeline multibranche vous permet également d’avoir différents environnements pour différentes branches. Cependant, il n’est pas recommandé d’utiliser un pipeline multibranche si vous n’avez pas de stratégie standard de branchement et de CI/CD.
Maintenant, puisque vous avez vu la comparaison entre le pipeline Jenkins et le pipeline multibranche, passons en revue les étapes pour créer un pipeline multibranche Jenkins.
Création d’un pipeline multibranche Jenkins
Étape 1
Ouvrez la page d’accueil de Jenkins (http://localhost:8080 en local) et cliquer sur «Nouvel article” dans le menu de gauche.
Étape 2
Entrer Nom du poste de Jenkins, choisissez le style comme « pipeline multibranche » et cliquez sur « D’ACCORD.”
Étape 3
Dans le « Csurfigure« , nous n’avons besoin de configurer qu’une seule chose : La source Git Repo.
Faites défiler jusqu’à « Sources des succursales » et cliquez sur le « Ajouter une source » menu déroulant.
Choisir « GitHub » comme source car notre exemple de référentiel GitHub y est hébergé.
Étape 4
Entrer le URL HTTPS du référentiel comme https://github.com/iamvickyav/spring-boot-h2-war-tomcat.git et cliquez sur « Valider.”
Étant donné que notre référentiel GitHub est hébergé en tant que référentiel public, nous n’avons pas besoin de configurer les informations d’identification pour y accéder. Pour les référentiels d’entreprise/privés, nous pouvons avoir besoin d’informations d’identification pour y accéder.
Le « Identifiants ok” Le message indique que la connexion entre le serveur Jenkins et le dépôt Git est réussie.
Étape 5
Laissez le reste des sections de configuration telles quelles pour le moment et cliquez sur le bouton « Sauvegarder” bouton en bas.
Lors de l’enregistrement, Jenkins effectuera automatiquement les étapes suivantes :
Analyser l’étape du référentiel
- Analysez le référentiel Git que nous avons configuré.
- Recherchez la liste des branches disponibles dans le référentiel Git.
- Sélectionnez les branches qui ont Jenkinsfile.
Exécution de l’étape de construction
- Exécutez la construction pour chacune des branches trouvées à l’étape précédente avec les étapes mentionnées dans Jenkinsfile.
Du « Analyser le journal du référentiel», nous pouvons comprendre ce qui s’est passé lors de l’étape Analyser le référentiel.
Puisque nous n’avons qu’un branche principale dans notre référentiel git, le journal du référentiel d’analyse indique « 1 succursales ont été traitées.”
Une fois l’analyse terminée, Jenkins créera et exécutera une tâche de build pour chaque branche traitée séparément.
Dans notre cas, nous n’avions qu’une seule branche appelée master. Par conséquent, la construction ne fonctionnera que pour notre branche principale. Nous pouvons vérifier la même chose en cliquant sur « Statut” dans le menu de gauche.
Nous pouvons voir une tâche de build créée pour la branche master dans la section status.
Cliquez sur le nom de la branche pour voir le journal et l’état de la tâche de build.
« Vue de la scène” donne une représentation visuelle du temps d’exécution de chaque étape et de l’état de la tâche de build.
Accéder aux journaux d’exécution des tâches de build
Étape 1
Clique sur le « Numéro de build » sous le « Historique de construction » section.
Étape 2
Ensuite, choisissez le « Sortie 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évelopper » est créé.
Pour différencier le «développer” branch build, nous avons apporté de petites modifications aux commandes echo dans Jenkinsfile.
Fichier Jenkins dans la branche principale
pipeline {
agent any
stages {
stage('Build Code') {
steps {
sh """
echo "Building Artifact"
"""
}
}
stage('Deploy Code') {
steps {
sh """
echo "Deploying Code"
"""
}
}
}
}Fichier Jenkins dans la branche Développer
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 référentiel dans Jenkins pour voir le comportement.
Nous pouvons voir que la nouvelle branche (développer la branche) 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évelopper”, nous pouvons voir le journal de la tâche de build de la branche develop.
Dans l’exemple précédent, nous avons conservé des contenus différents pour Jenkinsfile dans les branches master et develop . Mais ce n’est pas comme ça que nous procédons dans les applications du monde réel. Nous tirons parti des blocs when dans le bloc stage pour vérifier la branche.
Voici un exemple avec des étapes combinées pour les branches master et develop. Ce même contenu sera placé dans les deux branches master et develop Jenkinsfiles.
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
Cliquer sur « Référentiel d’analyse” dans le menu de gauche pour que Jenkins détecte les nouvelles modifications du référentiel Git.
À ce stade, vous avez peut-être remarqué que nous utilisons le référentiel d’analyse chaque fois que nous voulons que Jenkins détecte les modifications du référentiel.
Que diriez-vous d’automatiser cette étape ?