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 (Phobos).
3. Naviguer dans les dossiers système.
4. Lancer un git pull pour récupérer le code.
5. Reconstruire les conteneurs Docker manuellement.
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 ?
• Dans le futur, j’ajouterai ici des tests unitaires 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 au serveur.
• Mise à jour des fichiers.
• Relance des services.

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 (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é (pour éviter les attaques sur le port 22).
• SSH_KEY : Ma clé privée SSH (authentification cryptographique sans mot de passe).

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 une version simplifiée et sécurisée de mon script de déploiement (.github/workflows/deploy.yml) :

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 }}      # IP injectée
          username: ${{ secrets.SSH_USER }}  # User injecté
          key: ${{ secrets.SSH_KEY }}        # Clé privée injectée
          port: ${{ secrets.SSH_PORT }}      # Port personnalisé injecté
          script: |
            # On se place dans le dossier du projet
            cd /chemin/vers/mon/application
            
            # On récupère uniquement les modifications (Delta)
            git pull origin main
            
            # Reconstruction intelligente :
            # Docker ne recompile que ce qui a changé.
            # L'option -d (detach) rend la main immédiatement.
            docker compose up -d --build --remove-orphans

🎯 Pourquoi c’est un atout pour l’entreprise ?

Mettre en place ce système sur mon portfolio personnel démontre plusieurs compétences clés que j’apporterai en entreprise :

1. Productivité accrue : Je ne perds plus de temps sur des tâches répétitives à faible valeur ajoutée. Je me concentre sur le code et l’architecture.
2. Fiabilité : Le processus est déterministe. S’il marche une fois, il marchera mille fois.
3. Culture de la Sécurité : Gestion rigoureuse des accès, utilisation de clés SSH, ports non-standards et principe du moindre privilège.
4. Agilité : Je peux déployer 10 fois par jour si nécessaire, ce qui permet des itérations très rapides (fixer un bug en 2 minutes chrono).

Ce pipeline est la preuve qu’une infrastructure moderne, même pour un projet personnel, doit être pensée pour l’efficacité et la sécurité dès le premier jour.