Ressources / Déploiement
James Okoro
Ingénierie plateforme
Cinq habitudes pour déployer sans jamais couper le service.
Aucune n'est compliquée. Presque toutes sont oubliées jusqu'au premier incident.
Une coupure pendant une mise en production n'est pas une fatalité. C'est presque toujours le signe d'une habitude manquante, pas d'un manque d'outils.
Figer chaque version
Une version qui change après avoir été testée n’est plus la version testée. Chaque build doit produire un artefact immuable : un commit, une image. Quand tout est figé, savoir ce qui tourne en production ne demande plus d’enquête.
Déployer sur un serveur au repos
Installer la nouvelle version sur la machine qui sert déjà le trafic, c’est parier. Préparez-la plutôt sur un second serveur identique, laissez l’ancien servir les utilisateurs, et ne basculez qu’une fois la nouvelle version validée.
Notre meilleure décision a été de ne plus jamais toucher au serveur qui sert les clients.
Tester en conditions réelles
Un environnement de test qui ne ressemble pas à la production rassure à tort. Avant de basculer, vérifiez la nouvelle version avec les vraies variables d’environnement, les vrais volumes et un trafic représentatif.
Garder l’ancien serveur chaud
Le retour arrière n’est utile que s’il est instantané. Tant que l’ancien serveur reste allumé après la bascule, revenir en arrière se résume à repointer le DNS. Éteignez-le seulement quand vous avez la certitude que tout va bien.
Rendre la bascule banale
Plus une mise en production est rare, plus elle est risquée. Déployez souvent, par petits incréments, avec un geste identique à chaque fois. La répétition est la meilleure des protections.
Autres ressources.
Retours d’expérience, méthodes et avis sans filtre sur le déploiement et la souveraineté.
Tout voir
