DevOps, Pipelines CI/CD & Runbooks

1. Pipeline CI/CD et Stratégies de Déploiement

L'infrastructure d'Alta Voce est déployée sur des serveurs Gandi Simple Hosting (Apache/PHP en mode managé). Les déploiements du frontend et du backend s'appuient sur des pipelines automatisés (via GitHub Actions ou runners Gitlab) exécutant les étapes suivantes.

1.1. Déploiement du Backend (Laravel)

Le déploiement automatise le transfert des fichiers PHP et la compilation des dépendances.

graph TD
    A[Code validé sur branche principale] --> B[GitHub Action déclenchée]
    B --> C[Installation dépendances : composer install --no-dev]
    C --> D[Vérification de sécurité et Linter PHP]
    D --> E[Copie des fichiers via SFTP / Rsync vers Gandi]
    E --> F[Exécution des commandes post-déploiement via SSH]
    F --> G[Service opérationnel]

Commandes d'optimisation post-déploiement (exécutées via SSH sur Gandi) :

Après chaque mise à jour du code source sur le serveur, les caches doivent être vidés et régénérés pour maximiser les performances de PHP :

# Entrer dans le répertoire de production
cd /web/html/admin-alta

# Exécuter les migrations de base de données en mode non-interactif
php artisan migrate --force

# Régénérer le cache de configuration Laravel
php artisan config:cache

# Régénérer le cache de routage (accélère le matching d'API)
php artisan route:cache

# Compiler et mettre en cache les vues Blade
php artisan view:cache

# Compiler et mettre en cache les écouteurs d'événements (Events)
php artisan event:cache

1.2. Déploiement du Frontend (Vue.js 3)

Le frontend étant une Single Page Application (SPA) statique, il est entièrement compilé côté runner avant d'être poussé en production.

# Entrer dans le répertoire du client web
cd client-alta

# Installer les dépendances npm de production
npm ci

# Compiler et minifier le code source pour la production
npm run build

Le dossier résultant dist/ est ensuite transféré par le pipeline vers le dossier public /web/html/client-alta de l'hébergement Gandi.

2. Runbook de Gestion de Base de Données

Ce runbook décrit les procédures manuelles critiques de sauvegarde, de restauration et d'application de correctifs sur la base MySQL.

2.1. Sauvegarde et Export (Backup)

Avant toute mise à jour majeure de la base de données ou migration lourde :

# Sauvegarde complète de la base de données de production avec horodatage
mysqldump -u [user_db] -p[password_db] [name_db] > backup_altavoce_$(date +%F_%H%M%S).sql

[!WARNING] N'incluez pas d'espace entre le paramètre -p et votre mot de passe en ligne de commande.

2.2. Restauration d'une Sauvegarde (Rollback)

En cas d'échec critique lors d'une mise en production :

# Importer la sauvegarde SQL précédente dans la base de production épurée
mysql -u [user_db] -p[password_db] [name_db] < backup_altavoce_date.sql

2.3. Sécurisation des Migrations Laravel

Lors de l'ajout ou de la modification de tables en production :

  1. Éviter le verrouillage (Table Lock) : Sur les tables volumineuses comme telemetries (plusieurs millions de lignes), l'ajout d'une colonne peut bloquer les écritures. Il est recommandé de faire ces modifications durant les heures creuses (entre 23h et 04h du matin).
  2. Annulation de migration (Rollback) : Si une migration Laravel échoue à mi-parcours :
    php artisan migrate:rollback --step=1

3. Résolution d'Incidents Communs (Troubleshooting)

Ce guide de diagnostic rapide aide l'ingénieur de support ou DevOps à résoudre les pannes courantes de la plateforme Alta Call.

3.1. Incident A : Erreur HTTP 500 après un déploiement

  • Symptôme : L'Espace Client ou l'Espace Admin affiche une page blanche ou renvoie une erreur 500.
  • Cause possible : Cache Laravel corrompu ou incohérent avec le nouveau code.
  • Résolution : Connectez-vous en SSH au serveur backend et videz manuellement tous les caches système :
    php artisan cache:clear
php artisan config:clear
php artisan route:clear
php artisan view:clear

3.2. Incident B : Télémétries rejetées avec un code HTTP 403 / 401

  • Symptôme : L'application de bureau des agents ne parvient pas à transmettre ses diagnostics.
  • Cause possible : Clé de licence révoquée, invalide, ou token de sécurité manquant.
  • Résolution :
    1. Vérifiez dans l'interface Filament Admin (Resource Licenses) que la licence du groupe est active (valid = 1).
    2. Inspectez les logs PHP sous storage/logs/laravel.log pour repérer d'éventuelles erreurs de décryptage des tokens.

3.3. Incident C : saturation de l'espace disque du serveur (Disk Full)

  • Symptôme : Échec d'écriture en base de données, requêtes HTTP échouant aléatoirement.
  • Cause possible : Accumulation excessive des logs système ou des traces de débogage Telescope.
  • Résolution :
    1. Purger les fichiers logs obsolètes :
      rm storage/logs/laravel-*.log
    2. Vider le cache Telescope (Debug) :
      php artisan telescope:prune --hours=24
    3. Forcer le nettoyage de la télémétrie ancienne (conserve uniquement les 7 derniers jours) :
      php artisan abtest:prune-telemetry

3.4. Incident D : Les statistiques de la veille ne s'affichent pas dans l'Espace Client

  • Symptôme : Les graphiques décisionnels (Pitch F0, durées d'appels) restent vides pour la veille.
  • Cause possible : La tâche d'agrégation planifiée (summaries:build) a échoué ou ne s'est pas déclenchée.
  • Résolution :
    1. Déclenchez manuellement la commande de reconstruction des résumés :
      php artisan summaries:build
    2. Inspectez la sortie de la console pour identifier d'éventuels agents dont les télémétries corrompues bloqueraient le parsing mathématique.