Après le déploiement : que vérifier avant de crier victoire

Le pipeline passe au vert. Les artefacts de build sont téléversés. Le script de déploiement se termine sans erreur. De nombreuses équipes s'arrêtent là, en supposant que la nouvelle version est en ligne et fonctionne. Cette supposition est dangereuse.

Un pipeline vert signifie seulement que le processus de livraison s'est déroulé sans erreur technique. Cela ne signifie pas que la nouvelle version fonctionne réellement en production. Entre un pipeline réussi et un déploiement fonctionnel, il existe un fossé qui nécessite une vérification active.

Pourquoi le succès du pipeline ne suffit pas

Les environnements de production sont différents des environnements de staging ou de test. En production, votre nouvelle version fait face à des données réelles, des modèles de trafic réels et des conditions réseau réelles. Des choses se produisent qu'aucun pipeline ne peut détecter :

  • Une connexion à la base de données qui ralentit parce que le jeu de données de production est dix fois plus volumineux que celui du staging
  • Une configuration de cache qui fonctionne bien avec des requêtes de test mais échoue sur les modèles d'accès réels des utilisateurs
  • Un serveur mal configuré que le script de déploiement n'a pas détecté
  • Une API tierce qui répond différemment sous charge réelle

Le pipeline exécute des scripts et vérifie le code. Il ne sait pas comment le système se comporte lorsqu'il rencontre la réalité. C'est pourquoi vous avez besoin d'une étape distincte après le déploiement : la vérification.

La différence entre déploiement et vérification

Le déploiement est l'action de placer une nouvelle version dans un environnement. La vérification est l'action de confirmer que la nouvelle version fonctionne comme prévu dans cet environnement.

Ce sont deux activités différentes. Le déploiement concerne les machines et les scripts. La vérification concerne le comportement et les signaux. De nombreuses équipes les traitent comme une seule chose, ou sautent complètement la vérification parce que le pipeline a dit que tout allait bien.

Le diagramme suivant illustre comment le déploiement et la vérification sont des pistes séparées qui doivent toutes deux réussir avant qu'un déploiement ne soit considéré comme terminé :

flowchart TD A[Pipeline vert] --> B[Exécution du script de déploiement] B --> C[Artéfacts téléversés] C --> D[Piste de déploiement terminée] D --> E{Piste de vérification} E --> F[Test de fumée] F --> G{Réussi ?} G -- Non --> H[Rollback] G -- Oui --> I[Vérifier le taux d'erreur] I --> J{Dans le seuil ?} J -- Non --> H J -- Oui --> K[Vérifier la latence] K --> L{Dans les limites ?} L -- Non --> H L -- Oui --> M[Vérifier le débit] M --> N{Volume attendu ?} N -- Non --> H N -- Oui --> O[Déploiement terminé]

Dès l'instant où vous considérez le déploiement comme terminé lorsque le script se termine, vous pariez qu'aucun imprévu ne se produira en production. Ce pari peut fonctionner pour des changements simples. Pour tout ce qui implique des migrations de base de données, des changements de configuration ou des mises à jour d'infrastructure, les chances sont contre vous.

Commencez par un test de fumée

L'étape de vérification la plus basique est un test de fumée. Le terme vient de l'ingénierie matérielle : lorsque vous allumez un nouvel appareil pour la première fois, vous vérifiez si de la fumée s'en échappe. Pas de fumée signifie que l'appareil n'a au moins pas pris feu.

Dans le déploiement logiciel, un test de fumée est une vérification rapide pour voir si la nouvelle version est vivante et répond. Il répond à une question : cette version peut-elle accepter des requêtes et renvoyer des réponses raisonnables ?

Un test de fumée pratique peut inclure :

Voici un script bash minimal qui exécute un test de fumée contre un point de terminaison déployé et se termine avec un code non nul en cas d'échec :

#!/bin/bash
# smoke-test.sh - Vérification rapide que la version déployée est vivante

URL="https://votre-app.example.com/health"
EXPECTED_STATUS=200

HTTP_STATUS=$(curl -s -o /dev/null -w "%{http_code}" "$URL")

if [ "$HTTP_STATUS" -ne "$EXPECTED_STATUS" ]; then
    echo "Test de fumée échoué : statut attendu $EXPECTED_STATUS, reçu $HTTP_STATUS"
    exit 1
fi

echo "Test de fumée réussi : $URL a retourné $HTTP_STATUS"
exit 0
  • Atteindre la page principale et vérifier une réponse 200
  • Appeler un point de terminaison API simple et vérifier la structure de la réponse
  • Confirmer que la connexion à la base de données est active
  • Vérifier que les actifs statiques se chargent correctement

Les tests de fumée n'ont pas besoin d'être approfondis. Ce sont des vérifications rapides et superficielles qui détectent les échecs évidents. Si le test de fumée échoue, vous savez que quelque chose ne va pas sérieusement et devez arrêter le trafic supplémentaire ou effectuer un rollback. S'il réussit, vous pouvez passer à des vérifications plus détaillées.

Vérifiez les signaux de base

Une fois le test de fumée réussi, examinez les signaux opérationnels du système. Ce sont les métriques qui vous indiquent si la nouvelle version fonctionne normalement ou cause des problèmes.

Les signaux dont vous avez besoin dépendent de ce que vous avez déployé, mais certains sont universels :

  • Taux d'erreur : Le pourcentage de requêtes échouées est-il plus élevé qu'avant le déploiement ?
  • Latence : Les temps de réponse sont-ils dans des limites acceptables ? Un pic soudain indique souvent un problème.
  • Utilisation des ressources : L'utilisation du CPU, de la mémoire ou du disque a-t-elle changé de manière significative après le déploiement ?
  • Volume de trafic : Le système reçoit-il le nombre attendu de requêtes ? Une chute soudaine peut signifier que les utilisateurs ne peuvent pas atteindre la nouvelle version.

Vous n'avez pas besoin d'une analyse complexe pour cela. Comparez les valeurs actuelles avec la même fenêtre de temps avant le déploiement. Si vous avez un tableau de bord de surveillance, cette comparaison prend quelques minutes.

L'essentiel est de faire de cette vérification une partie standard de votre processus de déploiement, et non quelque chose que vous faites quand vous vous en souvenez ou quand quelqu'un signale un problème.

La vérification fait partie du déploiement

Voici le changement de mentalité : la vérification n'est pas une activité séparée qui se produit après le déploiement. La vérification fait partie du déploiement lui-même. Le déploiement n'est pas terminé tant que vous n'avez pas suffisamment confiance que la nouvelle version fonctionne normalement.

Cela a une conséquence pratique pour votre pipeline. Le pipeline ne doit pas marquer le déploiement comme réussi lorsque le script se termine. Il doit attendre que la vérification réussisse. Si la vérification échoue, le pipeline doit signaler le déploiement comme échoué, même si le script s'est exécuté sans erreur.

Certaines équipes mettent en œuvre cela en faisant en sorte que le pipeline fasse une pause après le déploiement et attende une confirmation manuelle. D'autres automatisent le test de fumée et les vérifications de signaux de base, et ne marquent le succès que lorsque ces vérifications réussissent. Les deux approches sont meilleures que de supposer que tout va bien.

Différents types de changements nécessitent des vérifications différentes

Tous les déploiements ne sont pas identiques. Une mise à jour d'application, une migration de base de données et un changement d'infrastructure ont chacun des risques différents et des signaux différents à vérifier.

Pour une mise à jour d'application, les principaux risques concernent le traitement des requêtes, l'exactitude des réponses et l'intégration avec les services existants. Les tests de fumée et les vérifications du taux d'erreur sont généralement suffisants.

Pour une migration de base de données, les risques sont différents. Vous devez vérifier que la migration s'est déroulée correctement, que l'intégrité des données est préservée et que les performances des requêtes ne se sont pas dégradées. Les vérifications des signaux doivent inclure l'utilisation du pool de connexions à la base de données, la latence des requêtes et le retard de réplication le cas échéant.

Pour un changement d'infrastructure, les risques concernent la connectivité, la disponibilité des ressources et l'exactitude de la configuration. Les vérifications des signaux doivent inclure la latence réseau, la validité des certificats et l'état de la découverte de services.

Le principe est le même : identifiez ce qui pourrait mal tourner pour ce type spécifique de changement, et vérifiez ces éléments avant de déclarer le déploiement terminé.

Une liste de contrôle pratique post-déploiement

Si vous voulez quelque chose de concret pour commencer, voici une liste de contrôle minimale qui fonctionne pour la plupart des applications web :

  • Le test de fumée réussit : page principale, points de terminaison API critiques, connexion à la base de données
  • Le taux d'erreur n'est pas plus élevé qu'avant le déploiement
  • La latence est dans la plage normale
  • L'utilisation du CPU et de la mémoire est stable
  • Aucun journal ou message d'erreur inhabituel dans les journaux d'application
  • Si une migration de base de données était impliquée : le statut de la migration est réussi, les performances des requêtes sont normales

Cette liste de contrôle n'est pas exhaustive, mais elle couvre les bases. Vous pouvez l'étendre à mesure que vous apprenez quels signaux sont les plus importants pour votre système spécifique.

L'essentiel à retenir

Un pipeline vert ne signifie pas un déploiement réussi. Le pipeline gère la mécanique de la livraison. La vérification gère la réalité de savoir si la nouvelle version fonctionne réellement. Ne considérez pas le déploiement comme terminé tant que vous n'avez pas vérifié que la nouvelle version fonctionne normalement en production. Cette seule habitude détectera les problèmes avant que vos utilisateurs ne le fassent.