Retour aux projets
27 novembre 2025 4 min de lecture

CI/CD : Automatisation Complète du Déploiement

#DevOps #GitHub Actions #CI/CD #Docker #Productivité

Comment j'ai éliminé les tâches manuelles et sécurisé la mise en production grâce à un pipeline GitHub Actions robuste et sans interruption de service.

Illustration de CI/CD : Automatisation Complète du Déploiement

🛑 Avant : La routine risquée du déploiement manuel

Il y a encore peu de temps, mettre à jour mon portfolio en production ressemblait à un rituel complexe et propice à l’erreur humaine. Pour changer une simple phrase ou une couleur, je devais :

  1. Ouvrir mon terminal.
  2. Me connecter en SSH à mon serveur distant.
  3. Naviguer manuellement dans l’arborescence système.
  4. Lancer un git pull pour récupérer le code.
  5. Reconstruire les conteneurs Docker.
  6. Prier pour ne pas avoir oublié une variable d’environnement ou cassé la config Nginx.

Cette méthode avait un coût : du temps mental, du stress, et un risque réel de “casser la prod” ou de créer une interruption de service (Downtime) pendant la manipulation.

🚀 Après : La Révolution CI/CD

Aujourd’hui, tout ce processus a disparu. J’ai mis en place un pipeline CI/CD (Intégration Continue / Déploiement Continu).

Concrètement ? Je pousse mon code sur GitHub, et 40 secondes plus tard, le site est à jour. C’est transparent, automatique et sécurisé.


🎓 Comprendre le concept : C’est quoi la CI/CD ?

C’est le cœur de la philosophie DevOps. L’idée est d’automatiser tout ce qui se passe entre le moment où je code et le moment où l’utilisateur voit le résultat.

1. CI (Continuous Integration) 🧪

C’est l’étape de vérification. À chaque fois que je modifie le code, un robot (ici GitHub Actions) vérifie que tout est propre.

  • Est-ce que le code compile ?
  • Est-ce que la structure du projet est valide ?
  • Roadmap : Ajout de tests unitaires et de linters automatiques.

2. CD (Continuous Deployment) 🔄

C’est l’étape de livraison. Si la CI est validée, le robot prend le relais pour livrer le “colis” (le code) sur le serveur, le déballer et l’installer.

  • Connexion sécurisée au serveur.
  • Mise à jour des fichiers.
  • Relance des services Docker.

Le bénéfice majeur : La constance. Un robot ne fait pas de fautes de frappe, n’oublie pas d’étapes et ne se fatigue pas, qu’il soit 10h du matin ou 3h du matin.


⚙️ L’Architecture Technique

Pour réaliser cela, j’utilise GitHub Actions, l’outil d’automatisation intégré à GitHub. Voici comment j’ai sécurisé le processus pour ne laisser aucune information sensible visible.

1. La Sécurité par les “Secrets” 🔐

La règle numéro 1 en sécurité : ne jamais écrire de mots de passe, d’IP ou de ports dans le code. J’utilise le coffre-fort numérique de GitHub (Repository Secrets) pour stocker les variables sensibles. Lors de l’exécution, le pipeline injecte ces valeurs dynamiquement.

  • SSH_HOST : L’adresse IP de mon serveur (cachée).
  • SSH_USER : L’utilisateur système dédié au déploiement (isolé du root).
  • SSH_PORT : Le port d’écoute SSH personnalisé (Hardening).
  • SSH_KEY : Ma clé privée SSH (authentification asymétrique).

2. Le Workflow “Zero Downtime”

L’objectif est que le site reste accessible même pendant la mise à jour. Grâce à l’architecture Docker, le redémarrage est quasi-instantané.

Voici le cœur de mon script de déploiement (.github/workflows/deploy.yml), nettoyé et commenté :

name: 🚀 Deploy to Production

# Déclencheur : Uniquement quand je valide du code sur la branche 'main'
on:
  push:
    branches: [ "main" ]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      # Étape 1 : GitHub récupère la dernière version de mon code
      - name: Checkout repository
        uses: actions/checkout@v4

      # Étape 2 : Connexion SSH sécurisée et exécution distante
      - name: Deploy via SSH
        uses: appleboy/ssh-action@v1.0.3
        with:
          host: ${{ secrets.SSH_HOST }}      # Injection sécurisée de l'IP
          username: ${{ secrets.SSH_USER }}  # Injection de l'utilisateur
          key: ${{ secrets.SSH_KEY }}        # Injection de la clé privée
          port: ${{ secrets.SSH_PORT }}      # Injection du port
          script: |
            echo "🔥 Début du déploiement..."
            
            # Navigation vers le dossier de l'application
            cd /var/www/portfolio
            
            # Récupération des modifications (Delta uniquement)
            git pull origin main
            
            # Reconstruction intelligente :
            # Docker ne recompile que les couches qui ont changé.
            # L'option -d (detach) rend la main immédiatement.
            docker compose up -d --build --remove-orphans
            
            echo "✅ Déploiement terminé avec succès !"
← Revenir aux projets