Mise en production

Mise en production

1. Publier sans casser, et ce qui casse quand même

   La publication est l'étape où les hypothèses de développement se vérifient. Ce qui a été supposé disponible localement ne l'est pas forcément.

   Les quatre différences d'environnement

   1. la configuration : clés de connexion, adresses d'API, seuils. Un environnement qui lit un fichier de configuration de développement se connecte au mauvais serveur, ou échoue au démarrage. C'est le défaut le plus fréquent, et il se voit immédiatement — ce qui en fait le moins coûteux ;
   2. les secrets : jamais dans le dépôt, jamais dans un fichier versionné. Ils viennent de l'environnement d'exécution ou d'un coffre, et l'application échoue au démarrage s'ils manquent — ce qui est le comportement voulu ;
   3. les migrations de base : appliquées automatiquement, elles peuvent s'exécuter deux fois si deux instances démarrent ensemble. La parade n'est pas de désactiver les migrations, mais de les rendre idempotentes et de sérialiser leur exécution ;
   4. la culture et le fuseau horaire : une sérialisation de date qui dépend de la culture produit un décalage d'un jour ou d'une heure selon la machine. Les dates se sérialisent en un format neutre, jamais en format local.

   La séquence de vérification avant ouverture

   • le même artefact est déployé sur tous les environnements, la configuration seule change ;
   • les migrations s'appliquent sur une base de staging proche de la production ;
   • le parcours critique est testé sur l'URL réelle ;
   • les journaux sont surveillés pendant les premières minutes, pas seulement le code de retour HTTP.

   Le point qui manque le plus souvent : une réponse 200 ne prouve pas que l'application fonctionne. Un 200 avec un corps d'erreur JSON, ou une page vide parce que la requête de données a échoué silencieusement, passe tous les tests de disponibilité. La vérification utile lit la réponse.

   Ce qu'il faut surveiller

   Le taux d'erreur par route et par code de statut, la latence au 95ᵉ centile — la moyenne masque les extrêmes —, la consommation mémoire, et le nombre de requêtes base de données par requête applicative. Ce dernier ne se voit pas dans les journaux applicatifs : il faut l'outillage de la base, et c'est là que traîne l'essentiel des problèmes de performance.