CI/CD : Écosystème et Infrastructure

CI/CD
Lecture
Cette leçon présente l’architecture complète d’un système CI/CD moderne, les différents composants nécessaires et les outils principaux pour chaque fonction. Nous verrons comment ces composants s’articulent dans une infrastructure conteneurisée.
Auteur
Affiliations

Emmanuel BRUNO

Université de Toulon

LIS UMR CNRS 7020

Date de publication

2026-10-06

Vue d’ensemble : Les composants d’un système CI/CD

Au-delà du simple pipeline : un écosystème complet

graph TB
    A[👨‍💻 Développeur] --> B[📦 Git Repository]
    B --> C[⚙️ Build Server]
    C --> D[🧪 Test Env]
    C --> E[📊 Quality Platform]
    C --> F[📚 Artifact Registry]
    F --> G[🐳 Image Registry]
    G --> H[☸️ Kubernetes]
    H --> I[🚀 Production]
    
   style B fill:#A8D5E2,color:#000
   style C fill:#B4E7A0,color:#000
   style E fill:#FFD6A5,color:#000
   style F fill:#E8B4E8,color:#000
   style G fill:#E8F4F8,color:#000
   style H fill:#A8D5E2,color:#000

7 composants essentiels

  1. Repository Git - Source de vérité
  2. Build Server - Orchestrateur
  3. Test Environments - Validation
  4. Quality Platform - Gardien
  5. Artifact Registry - Binaires
  6. Image Registry - Conteneurs
  7. Infra Deployment - Cible

Objectif : Comprendre le rôle et les outils de chaque composant

L’architecture moderne CI/CD

La vision complète : Du code à la production

%%{init: {
"theme": "base",
"themeVariables": {
"background": "#F7F9FC",
"primaryTextColor": "#2F2F2F",
"lineColor": "#B8C4CC",
"fontFamily": "Inter, Arial"
}
}}%%

graph LR
    subgraph S1["📦 Source Control"]
        A[GitHub<br/>GitLab<br/>Bitbucket]
    end
    
    subgraph S2["⚙️ CI/CD Platform"]
        B[GitHub Actions<br/>GitLab CI<br/>Jenkins]
        C[SonarQube<br/>Snyk]
    end
    
    subgraph S3["📚 Artifact Storage"]
        D[Nexus<br/>Artifactory]
        E[Docker Hub<br/>Harbor<br/>ECR]
    end
    
    subgraph S4["🚀 Deployment"]
        F[Kubernetes<br/>ECS<br/>Azure AKS]
    end
    
    A -->|Push| B
    B -->|Analyze| C
    B -->|Store| D
    D -->|Build| E
    E -->|Deploy| F
    
    %% Classes pour les nœuds
    classDef sourceControl fill:#CDE7F0,stroke:#9FC7D8,stroke-width:2px,color:#2F2F2F
    classDef cicd fill:#DFF2E1,stroke:#A8D5B5,stroke-width:2px,color:#2F2F2F
    classDef quality fill:#FFF1D6,stroke:#E5CFA3,stroke-width:2px,color:#2F2F2F
    classDef artifacts fill:#F5E6FF,stroke:#D4B8E8,stroke-width:2px,color:#2F2F2F
    classDef images fill:#E6F7FF,stroke:#B8DCF0,stroke-width:2px,color:#2F2F2F
    classDef deploy fill:#E8F5E9,stroke:#B8D8BA,stroke-width:2px,color:#2F2F2F
    
    %% Application des classes
    class A sourceControl
    class B cicd
    class C quality
    class D artifacts
    class E images
    class F deploy
    
    %% Styling des subgraphs
    style S1 fill:#EEF7FB,stroke:#9FC7D8,stroke-width:2px
    style S2 fill:#EFF9F1,stroke:#A8D5B5,stroke-width:2px
    style S3 fill:#FFF7E6,stroke:#E5CFA3,stroke-width:2px
    style S4 fill:#F0F8F0,stroke:#B8D8BA,stroke-width:2px

Les composants essentiels

Repository Git : La source de vérité

Single Source of Truth : Tout part du code

Rôle central

graph TB
    A[Git Repository] --> B[Code source]
    A --> C[Configuration]
    A --> D[Infrastructure]
    A --> E[Documentation]
    A --> F[Pipelines CI/CD]
    
    B --> G[Triggers CI/CD]
    C --> G
    D --> G
    F --> G
    
   style A fill:#A8D5E2,color:#000
   style G fill:#B4E7A0,color:#000

Fonctionnalités essentielles

✅ Gestion des branches & protection ✅ Pull/Merge Requests + code review ✅ Webhooks (déclenchement pipelines) ✅ RBAC & permissions granulaires

🔧 Plateformes Git

GitHub - SaaS + Enterprise - Actions CI/CD intégré - Communauté énorme - Usage : Open source, startups

GitLab - SaaS + Self-hosted gratuit - DevOps Platform complète - CI/CD natif puissant - Usage : Entreprises, on-premise

Bitbucket - Intégration Atlassian (Jira) - Pipelines CI/CD - Usage : Équipes Atlassian

Serveur de build : Orchestration des pipelines

Le chef d’orchestre de votre CI/CD

graph TB
    A[Git Event] --> B[Build Server]
    B --> C[Schedule Jobs]
    C --> D[Runner 1<br/>Build]
    C --> E[Runner 2<br/>Test Unit]
    C --> F[Runner 3<br/>Test IT]
    D & E & F --> G[Aggregate Results]
    G --> H[Notifications]
    G --> I[Store Artifacts]
    
   style B fill:#B4E7A0,color:#000
   style D fill:#E8F4F8,color:#000
   style E fill:#E8F4F8,color:#000
   style F fill:#E8F4F8,color:#000

Responsabilités

🎯 Orchestration (scheduler, dépendances) ⚙️ Exécution (runners, parallélisation) 📊 Reporting (logs, métriques, notifications)

🔧 Plateformes CI/CD

GitHub Actions - Intégré GitHub - YAML simple, marketplace - Usage : Projets GitHub

GitLab CI - Intégré GitLab - Puissant, flexible - Usage : Workflow DevOps complet

Jenkins - Open source, extensible - Plugins pour tout - Usage : Legacy, on-premise complexe

CircleCI / Travis CI - SaaS, config simple - Usage : Startups, projets open source

Environnements de test : Isolation et reproductibilité

Tester dans les bonnes conditions

Types d’environnements

Environnements de test:
  
  Unit Tests:
    - JVM isolée
    - Mocks/Stubs
    - Pas de dépendances
  
  Integration Tests:
    - Base de données
    - Message broker
    - Services externes
  
  E2E Tests:
    - Application complète
    - Frontend + Backend
    - Données réalistes

Solutions modernes

🐳 TestContainers

  • DB dans Docker
  • Éphémère et propre
  • Même version que prod

☸️ Preview Environments

  • K8s namespace par PR
  • URL unique
  • Auto-cleanup

🌐 Service Virtualization

  • Mock APIs externes
  • Contrôle des scénarios
  • Pas de dépendances

Plateforme de qualité : Gardien du code

La qualité comme prérequis, pas comme option

graph TB
    A[Code] --> B[Build Server]
    B --> C{Quality<br/>Gate}
    C -->|✅ Pass| D[Continue Pipeline]
    C -->|❌ Fail| E[Block Pipeline]
    
    C --> F[SonarQube<br/>Server]
    F --> G[Code Analysis]
    F --> H[Coverage Report]
    F --> I[Security Scan]
    F --> J[Technical Debt]
    
   style C fill:#FFD6A5,color:#000
   style D fill:#C5E1A5,color:#000
   style E fill:#FFD6A5,color:#000
    style F fill:#4A90E2

Analyses effectuées

📊 Code Quality (bugs, smells, complexité) 🧪 Test Coverage (lignes, branches) 🔒 Security (CVE, OWASP, secrets) 📈 Trends (dette technique)

🔧 Outils de qualité

SonarQube - Leader du marché - Self-hosted ou Cloud - Quality Gates - Usage : Toutes tailles d’équipe

Snyk - Focus sécurité (deps, code, containers) - Auto-fix PRs - Usage : Security-first teams

CodeClimate - SaaS simple - Maintenabilité focus - Usage : Startups, open source

Trivy - Open source - Scan containers + IaC - Usage : CI/CD security scans

Registre d’artefacts : Stockage des binaires

Stocker les résultats du build de manière persistante

Qu’est-ce qu’un artefact ?

graph LR
    A[Maven Build] --> B[JAR/WAR]
    C[NPM Build] --> D[.tgz]
    E[Go Build] --> F[binary]
    
    B & D & F --> G[Artifact<br/>Registry]
    
    G --> H[Versioned<br/>Storage]
    G --> I[Metadata]
    G --> J[Dependencies]
    
    style G fill:#BD10E0

Types : JAR/WAR, npm, wheels, binaries, NuGet

Bénéfices : Traçabilité, reproductibilité, partage, cache

🔧 Registres d’artefacts

Sonatype Nexus - Repository manager mature - Multi-format (Maven, npm, PyPI…) - Open source disponible - Usage : Entreprises, on-premise

JFrog Artifactory - Universal artifact repository - Cloud-native - 30+ formats - Usage : Cloud, scaling

GitHub Packages - Intégré GitHub - Zéro configuration - Usage : Projets GitHub

Registre d’images : Hub des conteneurs

Stocker et distribuer les images Docker

graph TB
    A[Dockerfile] --> B[docker build]
    B --> C[Image:<br/>myapp:v1.2.3]
    C --> D[docker push]
    D --> E[Container<br/>Registry]
    
    E --> F[Dev K8s]
    E --> G[Staging K8s]
    E --> H[Prod K8s]
    
    style E fill:#00D9FF
    style F fill:#E8F4F8
    style G fill:#F39C12
    style H fill:#27AE60

Caractéristiques : Tags versionnés, scan vulnérabilités, image signing, layers partagés

🔧 Registres d’images

Docker Hub - Registre public par défaut - Bibliothèque énorme - Usage : Images publiques, dev

Harbor - Open source self-hosted - Vulnerability scan intégré - RBAC avancé - Usage : Entreprises, on-premise

AWS ECR / GCP Artifact Registry - Managed cloud - Intégration native IAM - Scan automatique - Usage : Apps cloud (AWS/GCP)

Infrastructure de déploiement : Pourquoi Kubernetes ?

L’orchestrateur de conteneurs devenu standard

Avant Kubernetes

graph TB
    A[Docker Image] --> B{Où déployer?}
    B --> C[Serveur 1<br/>Manuel]
    B --> D[Serveur 2<br/>Manuel]
    B --> E[Serveur 3<br/>Manuel]
    
    C --> F[❌ Pas de HA]
    D --> F
    E --> F
    F --> G[❌ Scaling manuel]
    G --> H[❌ Rollback complexe]
    
    style F fill:#E74C3C
    style G fill:#E74C3C
    style H fill:#E74C3C

Avec Kubernetes

graph TB
    A[Docker Image] --> B[K8s API]
    B --> C[Deployment]
    C --> D[ReplicaSet]
    D --> E[Pod 1]
    D --> F[Pod 2]
    D --> G[Pod 3]
    
    H[Service] --> E & F & G
    I[Ingress] --> H
    
    style B fill:#326CE5
    style D fill:#7ED321

✅ Auto-scaling ✅ Self-healing ✅ Rolling updates ✅ Rollback 1-click

Orchestrateurs : Kubernetes, Docker Swarm, Docker Compose

Gérer le déploiement et le scaling des conteneurs

Kubernetes

☸️ Production

✅ Feature-rich ✅ Écosystème énorme ✅ Multi-cloud ✅ Auto-scaling ✅ Self-healing ✅ GitOps ready

❌ Complexité ❌ Courbe apprentissage

Market share : ~85%

Managed : - EKS (AWS) - GKE (Google) - AKS (Azure)

Usage : Production, toutes échelles

Docker Swarm

🐳 Petites équipes

✅ Simple setup ✅ Intégré Docker ✅ Courbe apprentissage douce ✅ Suffisant PME

❌ Moins de features ❌ Écosystème limité ❌ Pas de GitOps natif

Market share : ~5%

Usage : - Petites apps/équipes - Migration depuis Compose - Quand K8s est overkill

Docker Compose

🛠️ Dev / Prototypage

✅ Fichier YAML simple ✅ Démarrage instantané ✅ Idéal environnement local ✅ Reproductibilité dev

❌ Single-host uniquement ❌ Pas de HA ❌ Pas pour production

Usage : - Développement local - Prototypage rapide - CI/CD (tests IT) - Démo/proof-of-concept

⚠️ Non recommandé en production

Solutions intégrées vs Best-of-breed

Deux philosophies d’architecture CI/CD

🏢 All-in-One (Integrated)

graph TB
    A[GitLab Platform] --> B[Git]
    A --> C[CI/CD]
    A --> D[Registry]
    A --> E[Security]
    A --> F[K8s Deploy]
    A --> G[Monitoring]
    
    style A fill:#FC6D26

Exemples : - GitLab DevOps Platform - Azure DevOps - JFrog Platform - Atlassian Stack

Avantages : ✅ Intégration native ✅ Single UI/UX ✅ Un seul vendor ✅ Setup rapide ✅ Support unifié

Inconvénients : ❌ Vendor lock-in ❌ Moins flexible ❌ Pas toujours “best tool”

🔧 Best-of-Breed (Composable)

graph TB
    A[GitHub] --> B[Git]
    C[Jenkins] --> D[CI/CD]
    E[Nexus] --> F[Artifacts]
    G[Harbor] --> H[Images]
    I[Kubernetes] --> J[Deploy]
    K[Prometheus] --> L[Monitoring]
    
    B --> D
    D --> F
    F --> H
    H --> J
    J --> L

Approche : Meilleur outil pour chaque fonction

Avantages : ✅ Meilleur de chaque catégorie ✅ Flexibilité maximale ✅ Portable (multi-cloud) ✅ Éviter vendor lock-in

Inconvénients : ❌ Intégration complexe ❌ Multiple vendors ❌ Maintenance ++ ❌ Courbe apprentissage

Tout est conteneurisé

Un écosystème moderne CI/CD s’appuie largement sur des conteneurs : runners, environnements de test, outils de qualité, artefacts et infra déclarative.

Runners / agents CI (conteneurs)

  • Scalables et éphémères
  • Isolation des builds
  • Démarrage rapide

Environnements de test éphémères

  • TestContainers, namespaces K8s par PR
  • Reproductibilité des scénarios
  • Nettoyage automatique

Outils de qualité conteneurisés

  • SonarQube, Snyk, Trivy
  • Scans CI intégrés (SAST/SCA)
  • Rapports et Quality Gates

Applications déployées en conteneurs

  • Images versionnées et signées
  • Tags par environnement (dev/pr/staging/prod)
  • Scan vulnérabilités avant push

Infrastructure as Code (IaC) + conteneurs

  • Terraform / Helm / Kustomize
  • Déploiement déclaratif et reproductible
  • Intégration avec GitOps pour la synchronisation

Réutilisation