Projet · Phase 6.5

CI/CD (5/5) — Pipeline multibranch

Ton pipeline ne suit qu'une branche. Un vrai projet en a plusieurs — features, correctifs — qu'on veut construire automatiquement. Le pipeline multibranch découvre chaque branche seul et lui applique le Jenkinsfile.

⏱ ~1 h 30Niveau avancéPrérequis : CI/CD (4/5)Pratique · TP
L’idée reçue

« Un job Jenkins = une branche. Pour tester une autre branche, je recrée un job. »

Ça ne passe pas à l’échelle : un projet réel a des dizaines de branches qui vont et viennent. Créer et supprimer un job à la main pour chacune est intenable. Le pipeline multibranch résout ça : il découvre les branches du dépôt et applique le Jenkinsfile à chacune, automatiquement.

À la fin de ce module, tu sauras…

  • Expliquer ce qu’apporte un pipeline multibranch face à un pipeline simple
  • Créer un job Multibranch Pipeline sur ton dépôt
  • Configurer la découverte périodique des branches (scan)
  • Adapter le pipeline pour ne déployer que depuis main

01Le problème du job mono-branche

Ton job soria-web-ci ne regarde que main. Crée une branche feature/x, pousse-la : rien ne se passe. Jenkins ne la connaît pas.
Comprends ce que multibranch change

Un Multibranch Pipeline traite le dépôt entier, pas une branche : il scanne les branches, crée automatiquement un sous-job par branche contenant un Jenkinsfile, et le supprime quand la branche disparaît. Tu ne gères plus des jobs, tu gères un dépôt — Jenkins s’occupe des branches. Concept universel : GitLab CI et GitHub Actions appliquent aussi le pipeline à toutes les branches par nature.

02Créer le job Multibranch

Expérience 1

Un job qui suit tout le dépôt

Jenkins → New Item :

  1. Name : soria-web-multibranch · Type : Multibranch Pipeline
  2. Branch Sources → Add source → Git
  3. Repository URL : git@github.com:ton-compte/soria-web.git
  4. Credentials : github-soria-ssh (module 6.1)
  5. Build Configuration → Mode : by Jenkinsfile · Script Path : Jenkinsfile

Sauvegarde. Jenkins lance un premier scan du dépôt.

Observe
Scanned repository ...
Checking branch main
  'Jenkinsfile' found -> job created
1 branches were processed
Jenkins a découvert main, trouvé le Jenkinsfile, et créé un sous-job automatiquement. Chaque branche avec un Jenkinsfile aura le sien.
Comprends « by Jenkinsfile »

Le mode « by Jenkinsfile » dit à Jenkins : ne construis une branche que si elle contient un Jenkinsfile. C’est cohérent avec le pipeline-as-code : la définition du build voyage avec la branche. Une branche sans Jenkinsfile est simplement ignorée.

03Le scan périodique

Expérience 2

Découvrir les branches régulièrement

Le webhook prévient Jenkins des push, mais le scan sert à découvrir les branches nouvelles ou supprimées. Dans soria-web-multibranch → Configure → Scan Repository Triggers :

[x] Periodically if not otherwise run
  Interval : 1 minute
Jenkins re-scannera le dépôt chaque minute (s’il n’a pas déjà été déclenché autrement). Une nouvelle branche est ainsi prise en charge automatiquement, sans intervention.
Comprends scan vs build, et le « if not otherwise run »

Deux mécanismes distincts : le scan découvre les branches (structure du dépôt) ; le build exécute le pipeline sur une branche (déclenché par le webhook ou le scan). « If not otherwise run » évite le doublon : si un webhook a déjà déclenché l’activité, le scan périodique ne refait pas le travail. C’est un filet de sécurité pour ne rater aucune branche, même sans webhook fiable.

04Prouver la découverte automatique

Expérience 3

Une nouvelle branche, prise en charge seule

Manipule
cd ~/soria-web
git checkout -b feature/banniere
sed -i 's/<\/h1>/ - promo<\/h1>/' index.html
git commit -am "Test bannière promo"
git push -u origin feature/banniere

Attends au plus une minute (ou déclenche Scan Repository Now), puis regarde la vue du job multibranch.

Observe
Branches (2)
main               #4   OK
feature/banniere   #1   OK   <- apparue et construite toute seule
La branche feature/banniere a été découverte, et construite sans que tu crées de job. Supprime la branche sur GitHub : au scan suivant, son sous-job disparaît. Le cycle de vie des branches est géré tout seul.
Comprends pourquoi c’est puissant en équipe

Chaque développeur pousse sa branche et obtient un build automatique — feedback immédiat, avant même de fusionner. C’est la base du travail d’équipe que ton projet vise (interconnexion, dev collaboratif) : les branches sont testées en continu, sans configuration manuelle par branche.

05Ne déployer que depuis main

Expérience 4

Construire partout, déployer avec discernement

Attention : tu ne veux pas que chaque branche déploie en production ! On construit et teste partout, mais on ne déploie que depuis main. Encadre le stage Deploy par une condition :
Manipule
stage('Deploy (Helm)') {
when { branch 'main' }
steps {
  withCredentials([file(credentialsId: 'kubeconfig-soria', variable: 'KUBECONFIG_FILE')]) {
    sh '''
      set -eu
      export KUBECONFIG="$KUBECONFIG_FILE"
      helm upgrade --install soria-web ./soria-web \\
        -n lab-soria --set image.repository="$IMAGE_REPO" --set image.tag="$IMAGE_TAG"
    '''
  }
}
}
Désormais : toutes les branches passent par build + push (on vérifie que le code compile et produit une image) ; seule main exécute le Deploy. Sécurité et bon sens.
Comprends when { branch }, un garde-fou universel

La condition when { branch ‘main’ } rend un stage conditionnel à la branche. C’est un pattern standard : CI partout, CD seulement depuis la branche de production. Le même besoin existe dans tout outil (règles only/rules en GitLab CI, conditions if en GitHub Actions). Tu construis une culture, pas une syntaxe Jenkins.

✓Ce que tu retiens

Un pipeline multibranch gère un dépôt, pas une branche : il scanne et découvre les branches (périodiquement, « if not otherwise run »), applique le Jenkinsfile à chacune, et nettoie les branches disparues. On construit partout, mais on déploie seulement depuis main (when { branch ‘main’ }). Le CI/CD est désormais complet et adapté au travail d’équipe.

Mini-projet — clôture de la Phase 6

Un CI/CD prêt pour l’équipe

À faire

  1. Crée le job soria-web-multibranch sur ton dépôt.
  2. Active le scan périodique (Periodically if not otherwise run, 1 minute).
  3. Pousse une branche feature/… et prouve sa découverte + build automatiques.
  4. Ajoute when { branch ‘main’ } au Deploy et prouve qu’une feature ne déploie pas.
  5. Supprime la branche et vérifie que son sous-job disparaît au scan suivant.
  6. Documente dans BookStack : scan vs build, multibranch vs mono-branche, CI partout / CD depuis main.
Fil rouge — Ta chaîne de livraison est complète et automatisée. Mais toute ton infrastructure (VMs, cluster, config) a été montée à la main, étape par étape. Et si on pouvait la décrire dans du code, reproductible et versionnée ? À la Phase 7 : l’Infrastructure as Code avec Terraform & Ansible.

?Auto-évaluation

1. Qu’apporte un pipeline multibranch face à un job mono-branche ?

Il découvre automatiquement les branches du dépôt, crée un sous-job par branche avec Jenkinsfile, et les nettoie — sans gestion manuelle de jobs.

2. Quelle différence entre le scan et le build ?

Le scan découvre les branches (structure du dépôt) ; le build exécute le pipeline sur une branche. « If not otherwise run » évite que le scan double le travail déjà déclenché par un webhook.

3. Comment éviter que chaque branche déploie en production ?

Avec une condition when { branch ‘main’ } sur le stage Deploy : on construit partout, on ne déploie que depuis main.

Connecte-toi pour enregistrer ta progression.

Suite → Phase 7 — Infrastructure as Code (Terraform & Ansible)

Ce site utilise uniquement des cookies techniques, nécessaires à son fonctionnement. Aucun traceur, aucune publicité.