Qu'est-ce qu'un déploiement sain pour les applications, bases de données et infrastructures ?

Lorsqu'un déploiement se termine, comment savoir s'il a réellement fonctionné ? Pas le statut du pipeline. Pas la coche verte. Pas le message "déploiement réussi" dans Slack. La vraie question est : la chose que vous avez déployée fait-elle réellement ce qu'elle est censée faire ?

La réponse dépend de ce que vous avez déployé. Une application, une modification de base de données et une mise à jour d'infrastructure nécessitent chacune des vérifications différentes. Utiliser le même test de santé pour les trois revient à utiliser le même test pour vérifier si un moteur de voiture démarre, si l'huile est propre et si les pneus ont assez d'air. Tout est important, mais les vérifications diffèrent.

Vérifier un déploiement d'application

Commencez par la question la plus basique : le processus de l'application tourne-t-il et accepte-t-il des connexions ? C'est l'équivalent de vérifier si le serveur est allumé. Vous pouvez interroger un point de terminaison de santé simple et chercher une réponse 200. Si vous l'obtenez, l'application est vivante.

Le diagramme suivant montre les chemins de vérification distincts pour chaque type de déploiement, aboutissant à une décision de santé ou de rollback.

flowchart TD subgraph App[Application] A1[Test de santé] --> A2[Tests de fumée] A2 --> A3[Transactions synthétiques] A3 --> A4{Tout passe ?} A4 -->|Oui| A5[Sain] A4 -->|Non| A6[Rollback] end subgraph DB[Base de données] D1[Vérification migration] --> D2[Vérification intégrité données] D2 --> D3[Vérification performance requêtes] D3 --> D4{Tout passe ?} D4 -->|Oui| D5[Sain] D4 -->|Non| D6[Rollback] end subgraph Infra[Infrastructure] I1[Validation configuration] --> I2[Test connectivité] I2 --> I3[Vérification limites ressources] I3 --> I4{Tout passe ?} I4 -->|Oui| I5[Sain] I4 -->|Non| I6[Rollback] end

Mais être vivant ne signifie pas fonctionner. Une application qui accepte des connexions peut échouer dès qu'elle tente de traiter une requête. Elle peut ne pas être capable de lire son fichier de configuration. Elle peut échouer à se connecter à la base de données. Elle peut avoir une connexion cache cassée. Ces problèmes n'apparaîtront pas dans un simple test de santé.

C'est pourquoi la vérification d'application doit aller plus loin. Exécutez des tests de fumée qui appellent plusieurs points de terminaison en séquence. Simulez une transaction synthétique qui reflète ce qu'un utilisateur réel ferait : se connecter, rechercher quelque chose, soumettre un formulaire, se déconnecter. Si ce flux synthétique réussit, vous avez une preuve plus solide que l'application est réellement fonctionnelle, pas seulement en cours d'exécution.

Le point clé ici est de tester les parties qui comptent le plus pour vos utilisateurs. Si la fonctionnalité principale de votre application est la recherche par date, votre vérification doit inclure une requête de recherche qui utilise une plage de dates. Si les utilisateurs téléchargent des fichiers, votre vérification doit inclure un flux de téléchargement. Ne testez pas tout à chaque déploiement, mais testez les chemins critiques.

Voici un exemple pratique d'un test de santé et d'un script de transaction synthétique que vous pourriez exécuter après le déploiement :

# Health check: verify the app is alive
if curl -s -o /dev/null -w "%{http_code}" http://localhost:8080/health | grep -q "200"; then
  echo "Health check passed"
else
  echo "Health check failed"
  exit 1
fi

# Smoke test: simulate a core user flow (login, search, submit)
#!/bin/bash
set -euo pipefail

BASE_URL="http://localhost:8080"

# Step 1: Login
LOGIN_RESPONSE=$(curl -s -X POST "$BASE_URL/login" \
  -H "Content-Type: application/json" \
  -d '{"username":"testuser","password":"testpass"}')
TOKEN=$(echo "$LOGIN_RESPONSE" | jq -r '.token')

# Step 2: Search
SEARCH_RESPONSE=$(curl -s "$BASE_URL/search?q=test&date_from=2024-01-01" \
  -H "Authorization: Bearer $TOKEN")
if ! echo "$SEARCH_RESPONSE" | jq -e '.results | length > 0' > /dev/null; then
  echo "Search returned no results"
  exit 1
fi

# Step 3: Submit form
SUBMIT_RESPONSE=$(curl -s -X POST "$BASE_URL/submit" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"title":"test","content":"test content"}')
if ! echo "$SUBMIT_RESPONSE" | jq -e '.id' > /dev/null; then
  echo "Form submission failed"
  exit 1
fi

echo "Smoke test passed"

Vérifier une modification de base de données

Les bases de données ne parlent pas HTTP. Vous ne pouvez pas interroger un point de terminaison de base de données et obtenir une réponse 200. La vérification de base de données concerne les modifications de schéma, les modifications d'index, les procédures stockées et les mises à jour de données de référence. La question est : la migration s'est-elle exécutée sans erreur et a-t-elle cassé quelque chose qui fonctionnait avant ?

Commencez par exécuter le script de migration dans un environnement de staging d'abord. Vérifiez la sortie pour les erreurs. Si la migration a réussi, exécutez des requêtes de test qui représentent les modèles d'accès normaux de l'application. Si vous avez modifié un index, vérifiez si les requêtes qui dépendent de cet index s'exécutent toujours à une vitesse acceptable. Si vous avez modifié une procédure stockée, exécutez-la avec des données de test et vérifiez les résultats.

La vérification de base de données doit également confirmer qu'un rollback est possible. Un script de migration qui ne peut pas être annulé est un passif. Testez le rollback dans votre environnement de staging. Assurez-vous qu'il restaure l'état précédent proprement, sans perte de données ni corruption. Si vous ne pouvez pas effectuer un rollback en toute confiance, vous n'avez pas entièrement vérifié la modification.

Une erreur courante est de traiter la vérification de base de données comme une vérification ponctuelle. Les modifications de base de données peuvent avoir des effets subtils qui n'apparaissent que sous charge de production. Un nouvel index peut accélérer une requête mais en ralentir une autre. Une modification de schéma peut fonctionner correctement avec des données de test mais provoquer des problèmes de verrouillage avec des volumes de données réels. C'est pourquoi la vérification de base de données doit inclure à la fois des vérifications fonctionnelles et des vérifications de performance, même si les vérifications de performance sont de simples comparaisons de base.

Vérifier les modifications d'infrastructure

L'infrastructure couvre les serveurs, les équilibreurs de charge, les pare-feux, les enregistrements DNS, les certificats TLS et le routage réseau. Lorsque vous modifiez l'infrastructure, vous modifiez l'environnement dont tout le reste dépend. Un pare-feu mal configuré peut silencieusement casser les connexions à la base de données. Une règle d'équilibreur de charge erronée peut envoyer le trafic vers les mauvais serveurs. Un certificat TLS expiré peut rendre votre application inaccessible via HTTPS.

La vérification d'infrastructure concerne la connectivité et la configuration. Après avoir modifié une règle de pare-feu, vérifiez que l'application peut toujours atteindre la base de données. Après avoir mis à jour un équilibreur de charge, vérifiez que le trafic atteint les bons serveurs backend. Après avoir renouvelé un certificat TLS, vérifiez que les connexions HTTPS fonctionnent sans avertissements de sécurité.

Ces vérifications doivent souvent être exécutées depuis l'extérieur de l'infrastructure elle-même. Vous ne pouvez pas tester la connectivité externe depuis l'intérieur du réseau. Utilisez des scripts ou des outils qui simulent des connexions depuis l'extérieur. Interrogez les points de terminaison. Vérifiez la date d'expiration du certificat. Vérifiez que la résolution DNS renvoie les bonnes adresses IP.

Les modifications d'infrastructure ont également tendance à avoir des effets en cascade. La modification d'un enregistrement DNS peut affecter plusieurs services. La mise à jour d'une règle de pare-feu peut bloquer le trafic qui était auparavant autorisé. C'est pourquoi la vérification d'infrastructure doit inclure une carte de connectivité : une liste de toutes les connexions qui doivent fonctionner, et un test pour chacune.

Le principe commun

Même si les méthodes de vérification diffèrent, le principe est le même : chaque déploiement doit laisser une preuve que l'objet déployé fonctionne correctement. La preuve peut être une entrée de journal montrant une migration réussie, une réponse HTTP montrant que l'application peut servir des requêtes, ou un résultat de ping montrant qu'un serveur est joignable. Sans preuve, vous ne savez pas si le déploiement a réussi. Vous savez seulement que le pipeline s'est terminé.

Une liste de vérification pratique

Utilisez ceci comme point de départ, pas comme une liste finale. Ajustez-la en fonction de vos systèmes spécifiques.

  • Application : le point de terminaison de santé renvoie 200, la transaction synthétique pour le flux utilisateur principal réussit, les dépendances externes critiques (base de données, cache, API) sont joignables.
  • Base de données : le script de migration s'exécute sans erreur, les requêtes de test renvoient des résultats corrects, la performance des requêtes est dans une plage acceptable, le script de rollback fonctionne en staging.
  • Infrastructure : la connectivité entre tous les composants dépendants est vérifiée, les certificats TLS sont valides et n'expirent pas bientôt, la résolution DNS renvoie les enregistrements corrects, les règles de pare-feu autorisent le trafic requis.

Quand un déploiement est-il réellement terminé ?

Un déploiement est terminé lorsque vous avez vérifié que la modification fonctionne correctement dans son environnement. Pas lorsque le pipeline devient vert. Pas lorsque le ticket est fermé. Pas lorsque le chef d'équipe dit "ça a l'air bien". Le déploiement est terminé lorsque vous avez la preuve que l'application, la base de données ou l'infrastructure fait ce qu'elle est censée faire.

Cette preuve est ce qui distingue un déploiement qui a eu lieu d'un déploiement qui a réussi.