Le Déploiement Sacré

Stratégies de déploiement, GitHub Pages et versionnage sémantique

Qu'est-ce que le déploiement ?

Le déploiement (deployment), c'est le processus qui rend ton application disponible pour les utilisateurs. Tant que ton code reste dans un dépôt Git, personne ne peut l'utiliser. Le déploiement prend ce code et le met en ligne, sur un serveur, sur un site web - là où les gens peuvent y accéder.

Si la CI (intégration continue) vérifie que ton code fonctionne correctement, le CD (déploiement continu) s'assure qu'il arrive à destination.

Les environnements de déploiement

Avant de déployer directement en production, on utilise plusieurs environnements qui servent de filets de sécurité. Pense à ça comme des salles successives que traverse un parchemin avant d'atteindre la Grande Bibliothèque.

Développement (dev)

C'est ton environnement local. Là où tu écris, testes et expérimentes. Rien de ce que tu fais ici n'est visible par les autres.

# Tu travailles en local - c'est l'environnement de développement
git add .
git commit -m "Nouvelle fonctionnalité"

Staging (pré-production)

Un environnement qui imite la production mais qui n'est pas public. C'est l'avant-poste de préparation - on y vérifie que tout fonctionne dans des conditions réelles avant le grand jour.

• Même configuration que la production
• Données de test (pas de vraies données utilisateurs)
• Accessible uniquement à l'équipe

Production (live)

L'environnement réel, celui que les utilisateurs voient et utilisent. C'est la Grande Bibliothèque. Chaque erreur ici est visible par tous.

Les stratégies de déploiement

Comme un général choisit sa formation de bataille, un ingénieur choisit sa stratégie de déploiement. Chacune a ses avantages et ses risques.

1. Déploiement manuel

La méthode la plus simple : tu te connectes au serveur et tu copies les fichiers toi-même.

# Exemple simplifié - copier des fichiers sur un serveur
scp -r ./mon-site/ utilisateur@serveur:/var/www/html/

• Avantage : Simple à comprendre
• Inconvénient : Source d'erreurs humaines, pas reproductible

2. Déploiement automatique sur merge

Chaque fois qu'un merge est effectué sur la branche main, le déploiement se lance automatiquement. C'est la base du déploiement continu (CD).

# Le déploiement se déclenche quand on push sur main
on:
  push:
    branches: [main]

• Avantage : Rapide, fiable, reproductible
• Inconvénient : Nécessite une bonne suite de tests (sinon on déploie des bugs)

3. Blue-Green (Bleu-Vert)

On maintient deux environnements de production identiques : Blue (actuel) et Green (nouveau). On déploie sur Green, on teste, puis on bascule le trafic de Blue vers Green.

                    ┌──────────────┐
Utilisateurs ──────>│    Blue      │  (version actuelle)
                    └──────────────┘
                    ┌──────────────┐
   (en attente)     │    Green     │  (nouvelle version)
                    └──────────────┘

Après validation :

                    ┌──────────────┐
   (en attente)     │    Blue      │  (ancienne version)
                    └──────────────┘
                    ┌──────────────┐
Utilisateurs ──────>│    Green     │  (nouvelle version)
                    └──────────────┘

• Avantage : Rollback instantané (rebascule vers Blue)
• Inconvénient : Coût doublé (deux environnements)

4. Canary (Canari)

On déploie la nouvelle version sur un petit pourcentage d'utilisateurs d'abord. Si tout va bien, on augmente progressivement jusqu'à 100%.

Déploiement Canary - progression :

  5% ──> Nouvelle version    (test initial)
 95% ──> Ancienne version

 25% ──> Nouvelle version    (ça se passe bien)
 75% ──> Ancienne version

100% ──> Nouvelle version    (déploiement complet)

• Avantage : Risque minimal, détection précoce des problèmes
• Inconvénient : Plus complexe à mettre en place

5. Rolling (Progressif)

On met à jour les serveurs un par un au lieu de tous en même temps. Pendant la mise à jour, certains serveurs exécutent l'ancienne version et d'autres la nouvelle.

Serveur 1 : v2 ✓  (mis à jour)
Serveur 2 : v2 ✓  (mis à jour)
Serveur 3 : v1    (en attente)
Serveur 4 : v1    (en attente)

• Avantage : Pas de temps d'arrêt
• Inconvénient : Deux versions coexistent temporairement

GitHub Pages - Déployer un site depuis Git

GitHub Pages est le moyen le plus simple de déployer un site web statique directement depuis un dépôt Git. C'est gratuit et intégré à GitHub.

Comment ça fonctionne ?

GitHub prend le contenu de ton dépôt (HTML, CSS, JavaScript) et le publie sur un URL comme :

https://ton-pseudo.github.io/nom-du-repo/

Activer GitHub Pages

Déployer depuis une branche

Le plus simple. Sélectionne la branche main et le dossier racine / (ou /docs si tu préfères isoler les fichiers du site).

Déployer avec GitHub Actions

Plus puissant. Tu écris un workflow qui construit le site et le déploie. C'est ce que nous allons faire dans l'exercice.

Domaine personnalisé (custom domain)

Tu peux même utiliser ton propre nom de domaine au lieu de github.io. Il suffit de configurer un fichier CNAME dans ton dépôt et de mettre à jour les DNS de ton domaine. Pour l'instant, ce n'est pas nécessaire.

Les règles de protection d'environnement

Les environnements de production sont précieux. GitHub permet de définir des règles de protection pour éviter les déploiements accidentels.

Configurer un environnement protégé

Dans les Settings de ton dépôt, section Environments :

• Required reviewers : un ou plusieurs membres de l'équipe doivent approuver le déploiement
• Wait timer : délai obligatoire avant le déploiement (ex: 5 minutes)
• Deployment branches : seules certaines branches peuvent déclencher le déploiement

Utiliser un environnement dans un workflow

jobs:
  deploy:
    runs-on: ubuntu-latest
    environment: production    # <-- environnement protégé
    steps:
      - uses: actions/checkout@v4
      - name: Deploy
        run: echo "Déploiement en production..."

Quand le workflow atteint ce job, il attend l'approbation avant de continuer (si des reviewers sont requis).

Le rollback - Revenir en arrière

Parfois, malgré toutes les précautions, un déploiement introduit un bug. Il faut pouvoir revenir à la version précédente rapidement. C'est le rollback.

Stratégie 1 - Revert commit

Créer un nouveau commit qui annule les changements du commit problématique :

# Identifier le commit qui pose problème
git log --oneline

# Créer un commit qui annule ses changements
git revert abc1234

# Pousser le revert - le pipeline redéploie automatiquement
git push

L'avantage : l'historique reste propre et on voit clairement qu'un rollback a eu lieu.

Stratégie 2 - Redéployer une version précédente

Si tu utilises des tags de version, tu peux simplement redéployer le tag précédent :

# Revenir au tag v1.0.0
git checkout v1.0.0

# Ou dans un workflow, déclencher le déploiement d'un tag spécifique

Stratégie 3 - Blue-Green rollback

Avec la stratégie Blue-Green, le rollback est instantané : il suffit de rebasculer le trafic vers l'ancien environnement.

Workflow de déploiement complet

Voici un exemple de workflow GitHub Actions qui déploie un site statique sur GitHub Pages quand on pousse sur main :

name: Déployer sur GitHub Pages

on:
  push:
    branches: [main]

permissions:
  contents: read
  pages: write
  id-token: write

jobs:
  deploy:
    runs-on: ubuntu-latest
    environment: production
    steps:
      - name: Récupérer le code
        uses: actions/checkout@v4

      - name: Configurer GitHub Pages
        uses: actions/configure-pages@v4

      - name: Uploader l'artifact
        uses: actions/upload-pages-artifact@v3
        with:
          path: '.'

      - name: Déployer sur GitHub Pages
        uses: actions/deploy-pages@v4

Anatomie du workflow

Versionnage sémantique et tags pour les releases

Quand tu déploies, il est essentiel de numéroter tes versions pour savoir exactement ce qui est en production.

Le versionnage sémantique (SemVer)

Le format est vMAJEUR.MINEUR.PATCH :

v1.0.0
│ │ │
│ │ └── PATCH : correction de bug (rétro-compatible)
│ └──── MINEUR : nouvelle fonctionnalité (rétro-compatible)
└────── MAJEUR : changement incompatible (breaking change)

Créer un tag de version

# Tag léger
git tag v1.0.0

# Tag annoté (recommandé pour les releases)
git tag -a v1.0.0 -m "Première version stable"

# Pousser les tags vers GitHub
git push --tags

Créer une release sur GitHub

Les releases sont utiles pour les utilisateurs : elles offrent un point de téléchargement clair et un historique des changements.

Exercice pratique - Préparer le déploiement sacré

Étape 1 - Créer le dépôt

mkdir deploiement-sacre
cd deploiement-sacre
git init -b main

Étape 2 - Créer le site statique

Crée un fichier index.html :

cat > index.html << 'EOF'
<!DOCTYPE html>
<html lang="fr">
<head>
  <meta charset="UTF-8">
  <title>Les Chroniques du Royaume</title>
  <style>
    body { font-family: Georgia, serif; max-width: 800px; margin: 40px auto; padding: 0 20px; }
    h1 { color: #2c3e50; }
    .version { color: #7f8c8d; font-size: 0.9em; }
  </style>
</head>
<body>
  <h1>Les Chroniques du Royaume</h1>
  <p>Bienvenue dans la Grande Bibliothèque.</p>
  <p class="version">Version 1.0.0</p>
</body>
</html>
EOF

git add index.html
git commit -m "Créer la page d'accueil du site"

Étape 3 - Écrire le workflow de déploiement

Crée la structure de dossiers pour GitHub Actions :

mkdir -p .github/workflows

Crée le fichier de workflow :

cat > .github/workflows/deploy.yml << 'EOF'
name: Déployer sur GitHub Pages

on:
  push:
    branches: [main]

permissions:
  contents: read
  pages: write
  id-token: write

jobs:
  deploy:
    runs-on: ubuntu-latest
    environment: production
    steps:
      - name: Récupérer le code
        uses: actions/checkout@v4

      - name: Configurer GitHub Pages
        uses: actions/configure-pages@v4

      - name: Uploader l'artifact
        uses: actions/upload-pages-artifact@v3
        with:
          path: '.'

      - name: Déployer sur GitHub Pages
        uses: actions/deploy-pages@v4
EOF

git add .github/workflows/deploy.yml
git commit -m "Ajouter le workflow de déploiement GitHub Pages"

Étape 4 - Taguer la première version

git tag -a v1.0.0 -m "Première version stable - déploiement initial"

Vérifie que le tag existe :

git tag

Tu devrais voir v1.0.0 dans la liste.

Étape 5 - Lancer la vérification

bash verifier.sh

.\verifier.ps1

Récapitulatif des commandes

Récapitulatif des concepts