Que se passe-t-il après avoir cliqué sur Déployer : vérifier que votre nouvelle version fonctionne réellement
Le bouton de déploiement a été enfoncé. Le pipeline est vert. Votre équipe laisse échapper un soupir collectif. Mais si vous pensez que le travail est terminé, vous vous préparez un réveil brutal.
J'ai vu ce schéma se répéter dans d'innombrables équipes. Une nouvelle version est mise en production, tout le monde célèbre, et trente minutes plus tard, le premier ticket de support arrive. La fonctionnalité fonctionne en staging, mais en production, elle dévore la mémoire. L'API répond correctement à vos appels de test, mais le trafic utilisateur réel expose une condition de concurrence que personne n'avait détectée.
La mise en production n'est pas la ligne d'arrivée. C'est le moment où le vrai test commence.
Pourquoi le staging ne suffit pas
Votre équipe a probablement exécuté des tests avant la mise en production. Les tests unitaires ont passé. Les tests d'intégration étaient verts. L'environnement de staging semblait sain. Tout cela est bien, mais insuffisant.
Le staging n'a pas de vrais utilisateurs. Il n'a pas de volume de données réel. Il ne connaît pas les schémas de trafic imprévisibles que la production gère quotidiennement. Une requête de base de données qui s'exécute en 50 millisecondes en staging peut prendre cinq secondes en production parce que la table de production contient des millions de lignes. Une fonctionnalité qui fonctionne parfaitement avec des comptes de test peut casser lorsqu'elle est frappée par des jetons d'authentification provenant d'une douzaine de fournisseurs d'identité différents.
Ce fossé entre le staging et la production est la raison d'être des vérifications post-mise en production. Vous devez confirmer que la version qui tourne en production fonctionne réellement comme prévu, dans des conditions réelles.
Commencez par un test de fumée
La première chose à faire après une mise en production est un test de fumée. Le nom vient de l'électronique : lorsque vous allumez un circuit imprimé pour la première fois, vous vérifiez si de la fumée s'en échappe. Pas de fumée signifie que la carte ne brûle pas et que vous pouvez procéder à des tests plus approfondis.
En logiciel, un test de fumée est une vérification rapide pour voir si la nouvelle version est vivante. Vous accédez à la page principale et confirmez qu'elle se charge. Vous appelez un point d'API critique et vérifiez qu'il renvoie une réponse. Vous vérifiez que la connexion à la base de données est établie. Vous vous assurez que le flux de connexion ne plante pas immédiatement.
Les tests de fumée sont volontairement superficiels. Vous ne testez pas chaque fonctionnalité ou cas limite. Vous répondez à une seule question : le déploiement a-t-il réellement fonctionné, ou l'application est-elle cassée à l'arrivée ?
Le diagramme suivant cartographie le processus de vérification post-mise en production décrit dans cet article, y compris les points de décision pour le rollback.
Voici une commande bash simple que vous pouvez exécuter juste après le déploiement pour effectuer un test de fumée :
curl -f https://prod.example.com/health && echo "Smoke test passed" || echo "Smoke test failed"
Un bon test de fumée prend moins de deux minutes. Si vous l'avez automatisé, il s'exécute en quelques secondes. Si vous le faites manuellement, gardez la liste de contrôle courte. Cinq à dix vérifications maximum. Au-delà, vous glissez vers le territoire de la vérification.
Passez à la vérification
Une fois le test de fumée réussi, vous devez vérifier que la nouvelle version se comporte correctement. La vérification est plus systématique. Vous comparez le comportement réel du système à ce que vous attendiez.
C'est là que votre suite de tests existante redevient utile. Exécutez les tests critiques automatisés contre la production. Pas la suite de régression complète, mais le sous-ensemble qui couvre les fonctionnalités que vous venez de modifier. Si vous avez ajouté un nouveau flux de paiement, vérifiez que les commandes peuvent être passées. Si vous avez changé l'algorithme de recherche, vérifiez que les résultats de recherche ont du sens.
La vérification inclut également des contrôles manuels pour les choses difficiles à automatiser. Consultez les journaux pour détecter des erreurs inattendues. Regardez les données qui ont été traitées après la mise en production. Confirmez que la nouvelle fonctionnalité est accessible via l'interface utilisateur normale.
La différence clé avec le test de fumée est la profondeur. Le test de fumée demande « est-ce vivant ? ». La vérification demande « est-ce que ça fonctionne correctement ? ».
Surveillez les signaux de santé
Les tests de fumée et la vérification sont des contrôles actifs. Vous envoyez des requêtes et observez les réponses. Mais il existe une autre couche de vérification qui se fait passivement : la surveillance des signaux de santé.
Les signaux de santé sont les métriques qui vous indiquent si votre système est en bonne forme. Utilisation du CPU, consommation mémoire, taux de requêtes, taux d'erreur, temps de réponse, utilisation du pool de connexions à la base de données, profondeur de la file d'attente. Ces chiffres changent en continu à mesure que les utilisateurs interagissent avec votre système.
Après une mise en production, vous voulez surveiller ces signaux pour détecter des anomalies. Un pic soudain du taux d'erreur est un signal d'alarme. Une augmentation progressive de l'utilisation de la mémoire peut indiquer une fuite. Un temps de réponse qui augmente régulièrement pourrait signifier que le nouveau code est plus lent sous charge.
La différence entre les signaux de santé et les tests actifs est importante. Les tests actifs vous disent ce qui se passe lorsque vous demandez spécifiquement. Les signaux de santé vous disent ce qui se passe naturellement lorsque les utilisateurs utilisent le système. Les deux sont nécessaires.
Configurez des tableaux de bord qui affichent ces métriques côte à côte avec la référence de la version précédente. Mieux encore, configurez des alertes qui se déclenchent lorsque les métriques franchissent des seuils. Vous ne voulez pas découvrir un problème en fixant un graphique pendant une heure. Vous voulez que le système vous dise quand quelque chose ne va pas.
Combien de temps devez-vous vérifier ?
La durée des vérifications post-mise en production dépend du changement.
Pour un petit correctif de bogue ou l'ajout d'une fonctionnalité mineure, quelques minutes de test de fumée et d'observation des signaux de santé suffisent. Si rien ne casse dans les dix premières minutes, le changement est probablement sûr.
Pour une fonctionnalité majeure, une migration de base de données ou un changement d'infrastructure, vous avez besoin de plus de temps. Prévoyez de surveiller pendant plusieurs heures. Certaines équipes gardent un œil attentif pendant une journée ouvrable complète après une grosse mise en production. La raison est que certains problèmes mettent du temps à apparaître. Une fuite mémoire peut ne se manifester qu'après que le système a traité des milliers de requêtes. Une requête lente peut ne devenir visible que lorsque le nombre d'utilisateurs simultanés atteint un certain seuil.
L'important est de définir la période de vérification avant la mise en production. Mettez-vous d'accord sur ce que vous allez vérifier, pendant combien de temps, et quel seuil déclenche un rollback. Ne prenez pas ces décisions en plein milieu d'un incident.
Quand les choses tournent mal
Si vos vérifications post-mise en production trouvent un problème, vous devez décider quoi faire. La décision se résume généralement à deux options : hotfix ou rollback.
Un hotfix est approprié lorsque le problème est petit, isolé et peut être corrigé rapidement. Une faute de frappe dans une valeur de configuration. Une permission manquante sur un nouveau point d'API. Un problème CSS qui n'affecte qu'un seul navigateur. Vous pouvez le corriger et redéployer sans perturber les utilisateurs.
Un rollback est approprié lorsque le problème est grave. Corruption de données. Vulnérabilité de sécurité. Une fonctionnalité qui casse l'ensemble du flux utilisateur. Une régression de performance qui rend le système inutilisable. Dans ces cas, le moyen le plus rapide de restaurer le service est de revenir à la version précédente.
La décision doit être prise avant la mise en production, pas pendant la crise. Définissez ce qui constitue un problème digne d'un hotfix et ce qui constitue un problème digne d'un rollback. Documentez-le. Assurez-vous que tout le monde dans l'équipe connaît les critères.
Une liste de contrôle pratique post-mise en production
Voici une courte liste de contrôle que vous pouvez adapter pour votre équipe. Ajustez les éléments en fonction de votre application et de votre tolérance au risque.
- Test de fumée : la page principale se charge, l'API critique répond, la base de données est connectée
- Vérification automatisée : exécutez le sous-ensemble de tests qui couvre les fonctionnalités modifiées
- Vérification manuelle : consultez les journaux, confirmez que la nouvelle fonctionnalité est accessible
- Signaux de santé : examinez le taux d'erreur, le temps de réponse, l'utilisation des ressources
- Configuration des alertes : vérifiez que les alertes de surveillance sont actives et que les seuils sont définis
- Critères de rollback : confirmez que l'équipe sait ce qui déclenche un rollback et qui décide
Le véritable enseignement
La vérification post-mise en production n'est pas optionnelle. C'est l'étape qui sépare les équipes qui livrent en toute confiance de celles qui livrent et prient. L'objectif n'est pas d'éliminer tous les problèmes de production, c'est impossible. L'objectif est de détecter les problèmes rapidement, avant qu'ils n'affectent de nombreux utilisateurs, et d'avoir un plan clair pour réagir lorsque vous les trouvez.
Votre déploiement n'est pas terminé lorsque le pipeline devient vert. Il est terminé lorsque vous avez confirmé que la nouvelle version fonctionne correctement en production, sous un trafic réel, et que vos signaux de santé semblent normaux. C'est le moment où vous pouvez vraiment dire que la mise en production a réussi.