Préparer la mise en service et le retour arrière

Un déploiement peut démarrer correctement et pourtant dégrader le service quelques minutes plus tard : une file s’allonge, les exports épuisent les ressources ou une nouvelle version ne sait plus traiter les tâches déjà publiées. Pour réduire ce risque, préparez des contrôles qui donnent une décision claire avant la mise en service et une marche à suivre si les indicateurs se dégradent.

Dans la leçon précédente, vous avez construit des tests d’intégration à partir de dépendances injectées ; ils vérifient le comportement du service, mais ne remplacent pas les contrôles de déploiement ni la surveillance en production. La mise en service doit confirmer que l’application, ses dépendances, ses workers et ses procédures de reprise sont prêts ensemble.

Construire une checklist avant déploiement

Une checklist utile associe chaque contrôle à une preuve observable et à une personne responsable. Évitez les mentions vagues comme « tout est prêt » : indiquez plutôt quel test a réussi, quel tableau de bord doit être consulté et qui peut interrompre le déploiement. Gardez cette checklist liée à la version réellement déployée, pour pouvoir comparer l’état attendu à l’état constaté.

• Confirmez que les tests automatisés sont réussis et que l’artefact déployé correspond à la version testée.
• Vérifiez la configuration de l’environnement au démarrage : secrets présents dans le gestionnaire prévu, accès aux dépendances et paramètres validés par l’application.
• Vérifiez que la base, le stockage de la file et les services d’authentification sont joignables depuis les processus concernés.
• Confirmez que les migrations nécessaires sont exécutées ou planifiées, et que leur ordre est compatible avec la version actuellement en service.
• Vérifiez que le serveur web et le worker démarrent séparément, consomment la bonne configuration et peuvent recevoir les signaux d’arrêt prévus.
• Lancez une vérification fonctionnelle après déploiement : une requête protégée, une facture de test sur un environnement adapté et un export dont le résultat peut être contrôlé.
• Confirmez que les tableaux de bord, les journaux et les alertes sont accessibles à l’équipe de garde.

Pour un changement de schéma, privilégiez une évolution compatible avec les deux versions pendant la période de transition. Par exemple, ajoutez d’abord un champ facultatif que l’ancienne version ignore, déployez le code qui le renseigne, puis ne rendez ce champ obligatoire qu’après vérification. Une migration destructive, comme la suppression immédiate d’une colonne encore utilisée, rend souvent un retour arrière applicatif insuffisant.

Définir des seuils d’alerte exploitables

Un seuil d’alerte doit correspondre à un risque concret et déclencher une action. Les valeurs ci-dessous sont des points de départ illustratifs, pas des constantes universelles : mesurez votre trafic habituel et vos objectifs de service avant de les adopter. Une hausse isolée n’a pas toujours la même signification qu’une dégradation persistante accompagnée d’erreurs.

Choisissez des fenêtres d’observation assez longues pour éviter les alertes sur un pic bref, mais assez courtes pour agir avant une panne visible. Attribuez les alertes à une équipe et indiquez le premier diagnostic attendu : une alerte sans responsable, contexte ni action produit du bruit plutôt qu’une réponse opérationnelle. Réévaluez ces seuils après chaque incident significatif.

Préparer la reprise et le retour arrière

Un retour arrière consiste à rétablir une version connue comme fonctionnelle, pas simplement à redémarrer le processus. En cas de dégradation, arrêtez d’abord la progression du déploiement, notez l’heure et la version concernée, puis comparez les erreurs, la latence, la file et la mémoire avec leur niveau antérieur. Si le problème est circonscrit à une fonctionnalité coûteuse, désactivez-la seulement si un mécanisme déjà prévu le permet.

1. Décidez selon le critère d’arrêt défini : poursuivre, suspendre ou revenir à la version précédente.
2. Avant le retour, vérifiez la compatibilité entre cette version, le schéma de base et le format des tâches encore en file.
3. Rétablissez la version précédente selon la procédure de votre plateforme, puis contrôlez la santé du serveur et du worker séparément.
4. Vérifiez le traitement des tâches en attente : ne les republiez pas en masse et ne supprimez pas une file sans évaluer les commandes concernées.
5. Confirmez que les erreurs et indicateurs reviennent sous les seuils, puis informez les personnes concernées avec les faits observés.
6. Conservez les journaux utiles, les horodatages et les versions impliquées ; ouvrez ensuite une analyse de cause et définissez des mesures vérifiables.

À retenir

• Faites de la checklist un ensemble de preuves, de responsables et de décisions, pas une formalité.
• Définissez des seuils mesurables adaptés au trafic réel et associez chaque alerte à une action.
• Vérifiez la compatibilité des migrations et des tâches avant de considérer un retour arrière comme sûr.
• En incident, suspendez la progression, rétablissez une version connue et contrôlez séparément API, worker, file et données.
• Après la reprise, conservez les éléments de diagnostic et transformez les constats en corrections testables.

Vous disposez maintenant d’une base de décision pour mettre le service en production et organiser une reprise contrôlée lorsque les indicateurs se dégradent.