🛑 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 :
- Ouvrir mon terminal.
- Me connecter en SSH à mon serveur distant.
- Naviguer manuellement dans l’arborescence système.
- Lancer un
git pullpour récupérer le code. - Reconstruire les conteneurs Docker.
- 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 !"