À la fin de ce Capstone Project, vous aurez un pipeline CI/CD pour un microservice Maven banking : dépôt GitHub, branches et revues, build Maven/JUnit, image Docker taguée, job de test, e-mail, Ansible (Java + Apache) et conteneur sur la production.

Niveau : Intermédiaire · Temps estimé : 90–120 min · Versions cibles : Git 2.x · Maven 3.9+ · OpenJDK 17 · Jenkins 2.452+ · Docker Engine 27+ · Ansible 2.16+ · Ubuntu 24.04 LTS (ou RHEL 9) · Dernière vérification : 2026-09-11

Slug proposé : capstone-project · Série : DevOps · Leçon : CI/CD & Jenkins 11 / 11 · Publish : HOLD (feu vert Maître requis)

Prérequis

• Git : commit, branche, PR, merge
• Maven Build Tool : pom.xml, test / package
• Jenkins avec agent Maven + Docker
• Docker : Dockerfile, build, run, tags
• Bases Ansible : inventaire + playbook
• Compte GitHub + serveur Linux lab (Ubuntu 24.04 LTS) avec sudo
• SMTP lab (plugin Email Extension Jenkins)

Objectif : le brief client ABC (Agile, banking, microservices / REST API, SDLC encore manuel) devient un pipeline automatisé de bout en bout.

Ce que nous allons construire

Capstone BankingMicroservice (CI/CD & Jenkins 11/11)
  ├── Repo GitHub BankingMicroservice + README.md
  ├── Branches développeurs + revue → Master/main
  ├── Maven : App.java, src/test/, JUnit, JAR target/
  ├── Jenkinsfile : mvn → Docker build/tag/run → test dummy
  ├── E-mail si UNSTABLE
  ├── Ansible : Java + Apache sur prod
  └── Docker image/conteneur sur la prod

(Schéma à remplacer par une image locale, alt : « Pipeline Capstone BankingMicroservice de Git à Docker prod ».)

Étape 1 — Contexte métier ABC

ABC suit l’Agile pour un client banking. Le SDLC est encore trop manuel. Le client migre vers des microservices et des API REST et demande d’automatiser via CI/CD.

Ce Capstone clôture Jenkins (11/11). Vous êtes à la fois développeur et Code Reviewer.

Bloc brief	Livrable
Git	Repo BankingMicroservice, branches, revue, README
Maven	Build auto sur Master, JUnit, JAR dans target/
Docker	Dockerfile, image taguée, conteneur
Testing	Job dummy + e-mail si unstable
Prod	Ansible : Java + Apache démarré
Prod Docker	Image + conteneur sur le serveur Linux

Étape 2 — Git, branches et revue

Squelette Maven

mkdir -p BankingMicroservice/src/main/java/com/abc/banking
mkdir -p BankingMicroservice/src/test/java/com/abc/banking
cd BankingMicroservice

pom.xml (JUnit en dépendance — résolution automatique Maven) :

<project>
  <modelVersion>4.0.0</modelVersion>
  <groupId>com.abc.banking</groupId>
  <artifactId>banking-microservice</artifactId>
  <version>1.0.0</version>
  <properties><maven.compiler.release>17</maven.compiler.release></properties>
  <dependencies>
    <dependency>
      <groupId>org.junit.jupiter</groupId>
      <artifactId>junit-jupiter</artifactId>
      <version>5.10.2</version>
      <scope>test</scope>
    </dependency>
  </dependencies>
  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-surefire-plugin</artifactId>
        <version>3.2.5</version>
      </plugin>
    </plugins>
  </build>
</project>

App.java (main) et test sous src/test/ :

package com.abc.banking;
public class App {
  public static String health() { return "OK"; }
  public static void main(String[] args) { System.out.println(health()); }
}

package com.abc.banking;
import org.junit.jupiter.api.Test;
import static org.junit.jupiter.api.Assertions.assertEquals;
class AppTest {
  @Test void healthIsOk() { assertEquals("OK", App.health()); }
}

Repo GitHub BankingMicroservice

1. Créez le remote BankingMicroservice.
2. Commits locaux puis push remote (exigence brief).
3. Une branche par développeur (feature/dev-alice, …) ; push sur sa branche ; revue PR ; merge Master (ou main si c’est la convention lab — alignez Jenkins).
4. README.md distant : objectif, JDK/Maven/Docker, mvn test/package, Dockerfile, lien job Jenkins.

git init && git add . && git commit -m "feat: squelette Maven + JUnit"
git branch -M Master
git remote add origin git@github.com:<org>/BankingMicroservice.git
git push -u origin Master
git checkout -b feature/dev-alice

Tout changement sur App.java / tests est tracké et revu avant merge.

Étape 3 — Maven : build auto, JUnit, JAR

1. Build automatique dès update Master (webhook GitHub → Jenkins ou poll SCM).
2. Dépendances (JUnit) résolues par Maven.
3. JAR sous target/.

mvn -B clean test && mvn -B clean package && ls -la target/*.jar

Attendu : tests verts + banking-microservice-1.0.0.jar dans target/.

Étape 4 — Docker : image taguée et conteneur

Dockerfile dans le repo. À chaque changement fusionné : nouvelle image, nouveau tag, puis conteneur avec cette image.

FROM maven:3.9-eclipse-temurin-17 AS build
WORKDIR /app
COPY pom.xml . 
COPY src ./src
RUN mvn -B -DskipTests package

FROM eclipse-temurin:17-jre
WORKDIR /app
COPY --from=build /app/target/*.jar app.jar
ENTRYPOINT ["java","-jar","/app/app.jar"]

docker build -t banking-microservice:${BUILD_NUMBER:-local} .
docker run -d --name banking-ms banking-microservice:${BUILD_NUMBER:-local}
docker ps --filter name=banking-ms

Détails Engine / images : hub Docker.

Étape 5 — Jenkinsfile CI/CD + test + e-mail

Job Pipeline from SCM sur BankingMicroservice / Master, trigger push.

pipeline {
  agent any
  environment { IMAGE = "banking-microservice:${env.BUILD_NUMBER}" }
  stages {
    stage('Checkout') { steps { checkout scm } }
    stage('Maven Test & Package') {
      steps {
        sh 'mvn -B clean test package'
        archiveArtifacts artifacts: 'target/*.jar', fingerprint: true
      }
    }
    stage('Docker Build & Tag') {
      steps { sh 'docker build -t ${IMAGE} .' }
    }
    stage('Docker Run (lab)') {
      steps {
        sh 'docker rm -f banking-ms || true; docker run -d --name banking-ms ${IMAGE}'
      }
    }
    stage('Testing (dummy)') {
      steps {
        echo 'Test applicatif dummy — remplacer plus tard par intégration / smoke HTTP'
        sh 'docker exec banking-ms java -jar /app/app.jar || true'
      }
    }
  }
  post {
    unstable {
      emailext(
        subject: "[UNSTABLE] BankingMicroservice #${env.BUILD_NUMBER}",
        body: "Tests instables : ${env.BUILD_URL}",
        to: "${env.CHANGE_AUTHOR_EMAIL ?: 'developer@example.com'}"
      )
    }
    failure {
      emailext(
        subject: "[FAILED] BankingMicroservice #${env.BUILD_NUMBER}",
        body: "Échec pipeline : ${env.BUILD_URL}",
        to: "${env.CHANGE_AUTHOR_EMAIL ?: 'developer@example.com'}"
      )
    }
  }
}

Le brief autorise un job de test dummy. Alternative : job séparé post-build qui passe UNSTABLE sur smoke KO. Configurez SMTP + Email Extension : si unstable, mail au développeur (exigence CI).

Étape 6 — Prod Linux avec Ansible

Prod = Linux (Ubuntu ou Red Hat). Ansible doit :

1. Installer Java
2. Installer Apache
3. Démarrer Apache

[prod]
prod1 ansible_host=192.168.56.20 ansible_user=ubuntu

- hosts: prod
  become: true
  tasks:
    - name: Installer OpenJDK 17
      apt: { name: openjdk-17-jre-headless, state: present, update_cache: true }
      when: ansible_os_family == "Debian"
    - name: Installer Apache
      apt: { name: apache2, state: present }
      when: ansible_os_family == "Debian"
    - name: Démarrer Apache
      service: { name: apache2, state: started, enabled: true }
      when: ansible_os_family == "Debian"

ansible-playbook -i inventory.ini site.yml
java -version && systemctl status apache2

Sur RHEL : java-17-openjdk, httpd. Parcours Ansible ; alternative menu : Puppet.

Étape 7 — Docker sur la production

Répétez l’exigence Docker sur prod : rebuild/tag à chaque changement pertinent, puis conteneur avec la dernière image (SSH depuis Jenkins, ou modules community.docker).

docker build -t banking-microservice:prod-${BUILD_NUMBER} .
docker rm -f banking-ms-prod || true
docker run -d --name banking-ms-prod -p 8080:8080 banking-microservice:prod-${BUILD_NUMBER}

En entreprise : push registry puis docker pull en prod. Ensuite : orchestration Kubernetes.

Approfondissement — revue, webhook et qualité

En tant que Code Reviewer, exigez une PR avec description, lien ticket Agile (si Boards/Jira lab), et statut CI vert sur la branche feature avant merge Master. Protégez Master : pas de push direct, 1 approval minimum. Les commits restent d’abord dans le dépôt local de chaque développeur ; seul le travail validé part sur le remote BankingMicroservice.

Côté Jenkins, préférez un webhook GitHub (/github-webhook/) au poll SCM pour déclencher dès le merge Master. Vérifiez que l’agent a mvn, docker et les credentials SCM. Archivez le JAR (archiveArtifacts) pour tracer chaque build banking — utile si le client ABC demande un audit de livrable.

Pour le stage Testing dummy : vous pouvez forcer UNSTABLE avec catchError ou un script qui échoue volontairement une fois, afin de vérifier que l’e-mail part bien au développeur. Documentez l’adresse SMTP et le destinataire dans le README du Capstone.

Sur la prod, Apache n’héberge pas forcément l’API Java : il prépare le terrain (reverse proxy, health page statique, futur front). Java système reste utile pour outillage hors conteneur ; le runtime applicatif principal reste le JRE de l’image Docker.

Si vous êtes sur RHEL 9, remplacez les tâches apt/apache2 par dnf/httpd / java-17-openjdk-headless, et adaptez le nom de service. Gardez le même inventaire Ansible : un seul playbook avec when: ansible_os_family couvre Ubuntu et Red Hat, comme demandé par le brief (« Ubuntu or RedHat »).

Enfin, alignez le Capstone sur le reste du menu DevOps : outillage Git/Maven/Jenkins en amont, Docker/Ansible au milieu, puis ouverture vers Kubernetes et Nagios pour l’après-lab. Le client banking attend surtout un pipeline reproductible — pas une démo one-shot.

Pourquoi ce scénario banking reste pédagogique en 2026

Le brief ABC n’est pas un cas d’école décoratif : il force à relier des outils que les tutos isolent. Git sans revue produit un Master sale. Maven sans tests automatiques livre un JAR « qui compile chez moi ». Docker sans tag reproductible empêche de savoir quelle image tourne en prod. Jenkins sans e-mail laisse un UNSTABLE invisible. Ansible sans inventaire crée des snowflake servers. Le Capstone exige que chaque maillon parle au suivant.

Gardez le périmètre volontairement simple (un microservice, un dummy test, Apache « pour plus tard ») : le client banking veut d’abord un pipeline reproductible, pas un mesh de vingt services. Une fois le fil vert, vous pourrez remplacer le dummy par un smoke HTTP, pousser l’image vers un registry, et déployer sur Kubernetes avec un Service et une probe. Nagios viendra observer le port 8080 et Apache — après, pas avant, que le conteneur réponde.

Revue et qualité : ce que le Code Reviewer refuse

En tant que reviewer, refusez une PR sans description, sans lien avec le brief (ou un ticket Agile), et sans CI verte sur la branche feature. Exigez que App.java et les tests restent dans l’arbre Maven standard : un test « oublié » hors src/test ne sera jamais lancé par mvn test. Vérifiez que le Dockerfile n’embarque pas de secret (token GitHub, mot de passe SMTP) et que le tag d’image contient au moins le numéro de build Jenkins.

Protégez Master : pas de push direct, une approval minimum. Les développeurs committent d’abord en local sur leur branche ; seul le travail relu part sur le remote BankingMicroservice. C’est exactement le contrat Git du brief — et la raison pour laquelle le job Jenkins s’accroche à Master, pas à chaque branche feature (sauf si vous basculez plus tard en Multibranch).

Déclenchement, artefacts et audit

Côté Jenkins, préférez un webhook GitHub (/github-webhook/) au poll SCM. Vérifiez que l’agent a mvn, docker et les credentials SCM. Archivez le JAR (archiveArtifacts) : le client ABC peut demander un audit de livrable six semaines plus tard. Pour le stage Testing dummy, forcez une fois UNSTABLE (catchError ou script qui échoue) afin de prouver que l’e-mail part. Documentez SMTP et destinataire dans le README.

Sur la prod, Apache n’héberge pas forcément l’API Java : il prépare reverse proxy, page de santé, futur front. Java système sert l’outillage hors conteneur ; le runtime applicatif reste le JRE de l’image Docker. Sur RHEL 9, remplacez apt/apache2 par dnf/httpd / java-17-openjdk-headless grâce à when: ansible_os_family. Le brief dit « Ubuntu or RedHat » : un seul playbook, deux familles.

Alignez ensuite le Capstone sur le menu DevOps : Git / Maven / Jenkins en amont, Docker / Ansible au milieu, Kubernetes et Nagios pour l’après-lab. Vous n’avez pas « fini DevOps » : vous avez un fil rouge que vous pouvez montrer, rejouer et durcir.

Étape 8 — Check-list Capstone

• [ ] Repo BankingMicroservice + README.md
• [ ] App.java + tests src/test/, historique Git
• [ ] Branches dev, revue, merge Master
• [ ] mvn test / package → JAR target/
• [ ] Jenkins auto sur update Master
• [ ] Dockerfile, image taguée, conteneur lab
• [ ] Testing (dummy OK) + e-mail UNSTABLE
• [ ] Ansible : Java + Apache started
• [ ] Docker image + conteneur sur prod

Fil rouge à rejouer (pas une démo jetable)

Quand le pipeline est vert une fois, rejouez-le depuis une VM propre : clone, Wrapper ou Maven d’agent, build, image, playbook, conteneur. Si une étape dépend d’un fichier oublié sur votre laptop, le Capstone n’est pas terminé. Le client banking paie la reproductibilité, pas le souvenir d’un vendredi soir où « ça a marché ». Notez dans le README les versions (JDK, Maven, Jenkins LTS, Docker Engine, Ansible) et le nom exact de la branche protégée.

Erreurs fréquentes

• Webhook Jenkins muet : URL, token, branche Master/main
• docker: permission denied pour jenkins : groupe docker + restart agent
• JAR manquant : archiver après package seulement
• Mails absents : tester E-mail Notification ; Mailpit en lab
• RHEL : httpd, pas apache2
• Conteneur prod KO : docker logs banking-ms-prod

Aller plus loin

• Multibranch + SonarQube avant merge
• Registry + scan Trivy
• Apache ProxyPass vers le conteneur
• Déploiement K8s après ce Capstone mono-nœud — Kubernetes
• Supervision Nagios sur la prod lab

Conclusion

Brief ABC enrichi en parcours opérationnel : Git/revue, Maven/JUnit/JAR, Jenkins CI/CD, Docker tagué, tests + e-mail, Ansible Java/Apache, Docker prod. Chaque exigence du brief live (Git, Maven, Docker, Testing dummy, e-mail développeur, Ansible Java/Apache, Docker sur prod) est couverte sans suppression du fond pédagogique d’origine — uniquement densifiée en français, avec commandes et check-list.

Leçon 11/11 du fil CI/CD & Jenkins : pont entre les tutos outillage du menu DevOps et un scénario client banking réaliste (microservices, REST API, automatisation du SDLC).

Publish : densification FR QA58 — update post 209, enrichir sans supprimer le brief.

FAQ

Master ou main ?

Le brief dit Master. En 2026, main est fréquent. Une seule branche d’intégration protégée suffit — alignez Jenkins.

Le test peut rester dummy ?

Oui (brief). Remplacez ensuite par intégration ou smoke HTTP.

Ansible obligatoire avec Docker ?

Oui ici : Java + Apache sur le Linux prod font partie du périmètre.

Où mettre le Dockerfile ?

À la racine de BankingMicroservice, versionné avec le code.

Dans la série DevOps

• Jenkins
• Git – Distributed Version Control System
• Maven Build Tool
• Docker
• Ansible
• Kubernetes
• Nagios
• Puppet
• Capstone Project (cette page)