Mise en place d'un pipeline CI/CD (2/4)

Maximize Page

Tech & DevOps HubEspace Tech & DevOps: Explorez le monde du Dev, du Cloud et des outils DevOps à travers nos articles et discussions Explore the world of development, the cloud and DevOps tools

Share +

Mise en place d'un pipeline CI/CD (2/4) - La branche develop

Date de l'article:22-10-2025

CI/CD Github-Actions

Dans cette étape, je mets en place un pipeline orienté qualité pour la branche develop: build, tests, analyse statique Checkstyle/SpotBugs, scan CodeQL et Trivy, rapport SonarCloud. Nous détaillons la gestion du profil Spring avec la base H2 en contexte CI

INFO PROJET

App Spring Boot : Flashcards - readme CI

Docker Image Hub

Qualité/couverture: sonarCloud project

SonarQube Cloud

L'objectif est de mettre en place un workflow dédié par branche, d'y intégrer les étapes essentielles d'intégration continue: notamment Spotless, Checkstyle et SpotBugs, ainsi que l'exécution des tests et l'analyse de la couverture de code avec JaCoCo. Et, enfin d'ajouter un badge CI pour visualiser le status du pipeline

Stratégie multi-branches, rôle pour la branche "develop"

Pour structurer la CI/CD, j'ai choisi une stratégie multi-branches avec des responsabilités claires:

La branche [develop]: Garde-fou de la "Qualité"
→ Formatage, analyse statique, couverture du code, sécurité (scan des dépendances) seront ajoutés au worflow "ci-develop"
→ Rapide et léger. Il ne nécessite pas de coût d'infrastructure lourd (H2 en mémoire, pas de démarrage de l'app)
→ Protége la branche [main] avec plusieurs “gates” successifs (Qualité du code, tests automatisés, sécurité)

La séparation des responsabilités rend chaque pipeline plus lisible, plus facile à maintenir et, limite les effets de bord entre branches
L'idée est de garder un pipeline axé qualité sur cette branche.

1. Création de la branche:

#en partant de main

git switch -C develop
git push origin develop

* depuis la version 2.23, "git switch -c feature/" remplace avantageusement "checkout -b"
git checkout n'est pas supprimé, on peut continuer à l'utiliser Voir les Snippets Git

Voir le pipeline complet pour cette branche

2. Mise en place et étapes du pipeline

Le workflow est défini dans: .github/workflows/ci-develop.yml

name: CI - Develop
on:
  push:
    branches: [ develop ]
  pull_request:
    branches: [ develop ]
permissions:
  contents: read
  security-events: write

Le pipeline est déclenché sur les push/pull requests vers la branche develop

On lui donne ensuite les permissions:

contents: read est requis pour le job checkout (lire le repo)
security-events: write est requis pour CodeQL

Indispensable pour uploader ses résultats d'analyse
Onglet Security du dépôt Github

Le job principal: "build-and-test"

jobs:
  build-and-test:
    runs-on: ubuntu-24.04
    env:
      SPRING_PROFILES_ACTIVE: dev
      SPRING_DATASOURCE_URL: jdbc:h2:mem:itdb;DB_CLOSE_DELAY=-1
      SPRING_DATASOURCE_DRIVER_CLASS_NAME: org.h2.Driver
      SPRING_DATASOURCE_USERNAME: sa
      SPRING_DATASOURCE_PASSWORD:

Le job tourne sur Ubuntu 24.04

On définit des variables d'environnement globales pour orienter les tests vers une base de données H2 en mémoire. C'est une excellente pratique pour la phase de test car elle est beaucoup plus rapide que PostgreSQL

L'URL jdbc garantit que la base de données est créée uniquement pour la durée du job. Cela évite tout résidu de données entre les exécutions

Et voici, les étapes de base à la CI, elles seront reprises (et modifiées) par la suite dans les workflows [staging] et [main]

steps:
  - name: Checkout code
    uses: actions/checkout@v6.0.1
    with:
      fetch-depth: 0

  - name: Set up JDK 17
    uses: actions/setup-java@v5
    with:
      distribution: temurin
      java-version: '17'
      cache: maven

  - name: Validate formatting with Spotless
    run: ./mvnw spotless:check

  - name: Initialize CodeQL
    uses: github/codeql-action/init@v4.32.2
    with:
      languages: java

  - name: Run Maven clean verify
    run: ./mvnw -B clean verify jacoco:report

  - name: Upload JaCoCo report
    uses: actions/upload-artifact@v6
    with:
      name: jacoco-report
      path: target/site/jacoco/

  - name: Perform CodeQL analysis
    uses: github/codeql-action/analyze@v4.32.2

  - name: Scan dependencies with Trivy
    uses: aquasecurity/trivy-action@v0.28
    with:
      scan-type: fs
      scan-ref: .
      format: table
      severity: HIGH,CRITICAL

Les étapes du workflow et leurs actions

- name: Checkout code
Récupération du code source de la branche
fetch-depth: 0 permet un analyse complète

- name: Set up JDK 17
Java 17 est la version cible du projet et le cache Maven, accélère les builds

- name: Validate formatting with Spotless
Impose un formatage homogène du code avant de lancer les tests
ou l'analyse statique

- name: Initialize CodeQL
Détection des vulnérabilités et patterns dangereux dans le code Java

- name: Run Maven clean verify
Exécution des tests (unitaires et intégration),
tout en déclenchant Checkstyle et SpotBugs
Le but est de bloquer toute régression de qualité ou de tests

- name: Upload JaCoCo report
Le rapport de couverture est archivé comme artefact
Il peut être consulté depuis l'interface des Actions

- name: Perform CodeQL analysis
Exécution des requêtes CodeQL qui remonte les problèmes de sécurité
(onglet Security du dépôt GitHub)

- name: Scan dependencies with Trivy
Détection des vulnérabilités dans les dépendances
en se focalisant sur les niveaux HIGH et CRITICAL

1 artifact est produit à la fin de chaque build: jacoco-report (xml): 242 KB

Point important
La mise à jour de certaines actions CI/CD (dependabot) sont succeptible d'engendrer des modifications dans les workflows, images et/ou le code,
Le repository constitue dès lors, La source de vérité

CodeQL, Trivy, SonarCloud: trois niveaux de sécurité/qualité

CodeQL Fournit une analyse sémantique du code source Java pour détecter des vulnérabilités ou patterns dangereux (injections, mauvaises pratiques)

Trivy sur [develop] et [staging]: Il scan le File System pour les dépendances vulnérables (pom, libs Maven)
sur main: Il scan l'image Docker avant le push dans la registry, il peut bloquer la release si l'image contient des vulnérabilités

SonarCloud sur [main] uniquement: Agrège la couverture, les bugs, la vulnérabilités, le code smells, les duplications. Il applique aussi une Quality Gate bloquante

Même sur une branche purement "CI", on applique les mêmes outils de sécurité que sur la branche de production.
Cela garantit que les problèmes soient détectés au plus tôt, sans attendre un build de release

Profils Spring et base H2 pour les tests

Même si dev est le profil par défault, et actif de l'application, les tests JUnit utilisent des profils dédiés pour isoler les environnements de test

Les tests unitaires utilisent le profil "test", qui active automatiquement une base H2 en mémoire via src/test/resources/application-test.properties

Les tests d'intégration utilisent un profil "it" avec une configuration minimale, via src/test/resources/application-it.properties

Ce choix permet:

Des tests rapides, sans dépendance à une base externe
Un environnement totalement isolé par rapport aux profils dev/prod
Une exécution reproductible sur n'importe quel runner GitHub Actions,
sans configuration manuelle

Intérêt DevOps

[develop]: H2 = feedback ultra-rapide, zéro dépendance externe, idéal pour la boucle "dev → commit → CI"
[staging] / [main]: PostgreSQL en service container = validation “infra-réaliste” des migrations, de la config, des connexions réseau etc

Ajout du badge CI

Pour rendre la visibilité de la CI plus 'friendly', on ajoute un badge pour la branche

![CI - Develop](https://github.com/user/repo/actions/workflows/ci-develop.yml/badge.svg?branch=develop)

Les badges permettent de suivre l'état du pipeline, en un coup d'œil

Dans l'article suivant, nous passerons à la préparation de la branche staging, avec l'ajout des tests d'intégration

Naviguez entre les articlesBrowse through the articles