C'est quoi la CI/CD ?

Le problème que ça résout

Tu bosses sur un projet avec une équipe. Chacun code dans son coin pendant une semaine. Le vendredi soir, tout le monde pousse ses modifications. Résultat : conflits, régressions, et une nuit blanche pour tout remettre en état avant la livraison.

Et le déploiement ? Un développeur se connecte au serveur en SSH, copie les fichiers à la main, croise les doigts, et espère que rien ne plante en prod. Stressant, non-reproductible, risqué.

CI : l'Intégration Continue

La CI (Continuous Integration) consiste à intégrer les modifications de code en continu — c'est-à-dire dès qu'un développeur pousse du code. À chaque push, un pipeline automatique se déclenche : les tests tournent, le code est compilé, les dépendances sont vérifiées.

Le but : détecter les problèmes le plus tôt possible, quand ils sont encore faciles à corriger, plutôt qu'en découvrir dix en même temps le jour de la mise en production.

CD : la Livraison et le Déploiement Continus

Le CD se décline en deux variantes :

• Continuous Delivery (Livraison continue) : chaque version validée est prête à être déployée en production, mais le déclenchement reste manuel.
• Continuous Deployment (Déploiement continu) : chaque version validée est automatiquement déployée en production, sans intervention humaine.

La plupart des équipes commencent par la livraison continue (un humain appuie sur le bouton) avant de passer au déploiement continu une fois la confiance dans les tests bien établie.

Le pipeline CI/CD : de l'idée à la prod

Un pipeline CI/CD est une suite d'étapes automatisées qui transforme ton code source en application déployée. Voici le flux typique :

# Flux typique d'un pipeline CI/CD

1. PUSH      →  Le développeur pousse du code sur GitHub
2. TRIGGER   →  GitHub Actions détecte l'événement et démarre le workflow
3. INSTALL   →  Téléchargement des dépendances (npm install, composer install…)
4. LINT      →  Vérification du style de code
5. TESTS     →  Exécution des tests unitaires et d'intégration
6. BUILD     →  Compilation / génération des artefacts
7. DEPLOY    →  Déploiement automatique sur le serveur ou le cloud

# Si une étape échoue → le pipeline s'arrête, notification envoyée
# Si tout passe → l'app est en prod en quelques minutes

Pourquoi GitHub Actions ?

Il existe plusieurs outils de CI/CD : Jenkins, GitLab CI, CircleCI, Travis CI… Mais GitHub Actions a pris une place dominante pour plusieurs raisons :

• Intégré à GitHub : pas besoin d'un service externe. Ton code et ton pipeline sont au même endroit.
• Gratuit pour les repos publics : idéal pour les projets open-source.
• Marketplace : des milliers d'actions prêtes à l'emploi (déployer sur AWS, envoyer une notif Slack, publier sur npm…).
• YAML natif : les workflows se définissent en YAML, versionnés avec ton code.
• Runners hébergés : GitHub fournit des machines virtuelles Ubuntu, Windows et macOS pour exécuter tes pipelines.

Les concepts clés de GitHub Actions

Avant d'écrire ton premier workflow, il faut maîtriser le vocabulaire :

• Workflow : un fichier YAML dans .github/workflows/ qui décrit tout le pipeline. Un repo peut en avoir plusieurs.
• Trigger (on) : l'événement qui déclenche le workflow — push, pull_request, schedule, etc.
• Job : un groupe d'étapes qui s'exécutent sur la même machine. Les jobs tournent en parallèle par défaut.
• Step : une étape individuelle dans un job — une commande shell ou une action réutilisable.
• Runner : la machine (virtuelle) sur laquelle le job s'exécute. GitHub en fournit, ou tu peux utiliser le tien.
• Action : un bloc de code réutilisable publié sur le Marketplace (ex. actions/checkout, actions/setup-node).

Un exemple concret : push → tests → déploiement

Voici à quoi ressemble un workflow GitHub Actions réel. Il se déclenche à chaque push sur la branche main, installe les dépendances Node, lance les tests, puis déploie l'application.

name: CI/CD Pipeline

on:
  push:
    branches:
      - main       # Se déclenche uniquement sur main

jobs:
  test-and-deploy:
    runs-on: ubuntu-latest    # Runner Ubuntu fourni par GitHub

    steps:
      # Étape 1 : récupérer le code source
      - name: Checkout du code
        uses: actions/checkout@v4

      # Étape 2 : configurer Node.js
      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'

      # Étape 3 : installer les dépendances
      - name: Installer les dépendances
        run: npm ci

      # Étape 4 : lancer les tests
      - name: Lancer les tests
        run: npm test

      # Étape 5 : déployer (uniquement si tests OK)
      - name: Déployer sur le serveur
        run: npm run deploy
        env:
          DEPLOY_KEY: ${{ secrets.DEPLOY_KEY }}  # Clé stockée dans les secrets GitHub

Ce que ça change concrètement

Avec un pipeline CI/CD en place, voici ce qui change dans ton quotidien de développeur :

• Tu pousses du code — les tests tournent automatiquement en 2 minutes.
• Une pull request bloquée par des tests en rouge = problème identifié avant la fusion, pas après.
• Le déploiement n'est plus une opération stressante du vendredi soir, c'est un événement banal et automatisé.
• L'historique des exécutions dans GitHub te montre exactement quand et pourquoi un pipeline a échoué.