Build Tools, Docker & CI/CD DevOps

L'évolution des pratiques DevOps a profondément changé la façon de builder et déployer les applications. Docker et les pipelines CI/CD ont remplacé la gestion manuelle des artifacts.

Évolution : de l'artifact classique à Docker

Avant Docker — gestion complexe des artifacts

Java App  →  JAR file   ─┐
JS App    →  ZIP file   ─┤─► Plusieurs types d'artifacts
Python    →  WHL file   ─┘    Plusieurs repositories
                               Installation des deps sur chaque serveur

Problèmes :

• Chaque langage produit un type d'artifact différent
• Besoin d'un repository par type de fichier
• Installer les dépendances (Java, Node.js...) sur chaque serveur de déploiement
• Configurations différentes entre dev, test et prod

Avec Docker — 1 seul type d'artifact

Java App  ─┐
JS App    ─┤─► Docker Image ──► Docker Registry ──► Serveur
Python    ─┘    (1 format)       (1 seul repo)       (aucune installation requise)

Avantages :

• 1 seul format d'artifact : la Docker Image
• 1 seul repository : Docker Registry (Docker Hub, ECR, GCR...)
• Pas d'installation de dépendances sur le serveur
• Tout s'exécute à l'intérieur de l'image

Build Tools & Docker — Comment ça fonctionne

Workflow avec Docker

1. Builder l'application avec l'outil de build
   gradle build  →  build/libs/app.jar
   npm run build →  dist/

2. Créer la Docker Image avec le Dockerfile
   docker build -t mon-app:1.0 .

3. Pousser vers le Docker Registry
   docker push mon-app:1.0

4. Sur le serveur : juste docker run !
   docker run mon-app:1.0

Exemple de Dockerfile — Application Java (Gradle)

FROM amazoncorretto:17-alpine-jdk

EXPOSE 8080

# Copier le JAR buildé dans l'image
COPY ./build/libs/java-app-1.0-SNAPSHOT.jar /usr/app/

WORKDIR /usr/app

ENTRYPOINT ["java", "-jar", "java-app-1.0-SNAPSHOT.jar"]

# Séquence complète
gradle build                              # 1. Builder le JAR
docker build -t mon-app:1.0 .            # 2. Créer l'image Docker
docker push registry.exemple.com/mon-app:1.0  # 3. Publier l'image
docker run -p 8080:8080 mon-app:1.0      # 4. Exécuter sur le serveur

Comparaison — Avec vs Sans Docker

On ne supprime pas les outils de build (Maven, npm...) — on les utilise toujours. Docker encapsule simplement le résultat dans une image standard.

Pourquoi les ingénieurs DevOps doivent maîtriser ces outils

Un ingénieur DevOps n'écrit pas l'application, mais il doit comprendre et configurer le processus de build pour les pipelines CI/CD.

Rôle du DevOps dans le build

Développeur          DevOps Engineer
────────────         ──────────────────────────────
Écrit le code        Configure le pipeline CI/CD
Définit le build     Exécute le build sur les serveurs
  (pom.xml,          Configure les serveurs de build
   package.json)     Intègre avec les outils de déploiement
                     Sait lire et comprendre les erreurs de build

Cas concrets :

• Un dev te demande : "Pourquoi mon mvn install échoue sur Jenkins ?"
• Tu dois configurer Jenkins pour exécuter npm test et docker build
• Tu dois comprendre si un artifact est prêt pour la prod

Pipeline CI/CD — Le flux complet

CI (Continuous Integration) = à chaque merge, le code est automatiquement testé et buildé. CD (Continuous Delivery/Deployment) = l'artifact est automatiquement déployé.

Développeur fait un git push
          │
          ▼
┌─────────────────────────────────────────────────────────┐
│                   PIPELINE CI/CD (Jenkins)               │
│                                                         │
│  1. Install deps    2. Run tests    3. Build app        │
│  ─────────────      ───────────     ──────────────      │
│  npm install        npm test        npm run build       │
│  mvn install        mvn test        mvn package         │
│                                     docker build        │
│                                                         │
│  4. Push to repo                                        │
│  ─────────────────────────                              │
│  npm publish                                            │
│  docker push registry/app:tag                           │
│                                                         │
└─────────────────────────────────────────────────────────┘
          │
          ▼
   Serveur de production
   docker run app:tag

Avantage clé : tout s'exécute sur le serveur CI (Jenkins), pas en local. Le développeur pousse son code — le pipeline s'occupe de tout.

Outils de CI/CD

Exemple de pipeline GitLab CI

# .gitlab-ci.yml
stages:
  - test
  - build
  - deploy

test:
  stage: test
  script:
    - npm install
    - npm test

build:
  stage: build
  script:
    - npm run build
    - docker build -t mon-app:$CI_COMMIT_SHA .
    - docker push registry.gitlab.com/user/mon-app:$CI_COMMIT_SHA

deploy:
  stage: deploy
  script:
    - docker pull registry.gitlab.com/user/mon-app:$CI_COMMIT_SHA
    - docker run -d -p 80:3000 mon-app:$CI_COMMIT_SHA

Récapitulatif — Les outils selon le contexte

En développement local

# Java
mvn install          # Installer deps + build + tests
java -jar app.jar    # Lancer l'application

# JavaScript
npm install          # Installer les dépendances
npm start            # Démarrer en mode développement
npm test             # Lancer les tests

En CI/CD (Jenkins, GitLab CI...)

# Le pipeline exécute automatiquement :
mvn test             # Tests
mvn package          # Build du JAR
docker build         # Création de l'image
docker push          # Publication dans le registry

En production

# Le serveur n'a besoin que de Docker
docker pull mon-app:1.0
docker run -d -p 8080:8080 mon-app:1.0

À retenir

• Docker Image = l'artifact universel qui remplace JAR, ZIP, WAR selon le contexte
• Dockerfile = instructions pour créer l'image à partir de l'application buildée
• On build toujours avec Maven/Gradle/npm avant de créer l'image Docker
• CI/CD Pipeline : install deps → run tests → build app → push to registry → deploy
• Jenkins / GitLab CI / GitHub Actions = outils qui automatisent ce pipeline
• DevOps engineer : configure le pipeline, comprend les outils de build, n'exécute pas en local
• Avantage Docker : 1 type d'artifact, 1 registry, pas d'installation de deps sur les serveurs
• Sans Docker : gérer JAR, ZIP, WHL... chacun dans son repo → complexité opérationnelle