Pourquoi les déploiements cassent, et comment nous l’évitons
La plupart des pannes pendant une mise en production viennent de l’intervalle entre l’arrêt de l’ancienne version et le démarrage de la nouvelle, ou d’une nouvelle version qui démarre sans parvenir à servir les requêtes. Les déploiements sans coupure suppriment cet intervalle : l’ancienne version continue de répondre jusqu’à ce que la nouvelle ait prouvé qu’elle est saine.
Ce qui se passe à chaque déploiement
Aucune configuration n’est nécessaire pour bénéficier de déploiements sûrs. Un contrôle de santé par défaut s’exécute sur chaque service web, et vous pouvez le diriger vers votre propre endpoint pour une vérification plus stricte.
- Les nouvelles instances démarrent avant l’arrêt des anciennes
- Le trafic ne bascule qu’après la réussite des contrôles de santé
- Un déploiement en échec ne reçoit jamais de trafic
Revenir en arrière
Chaque build réussi est conservé comme cible de retour arrière. Revenir en arrière redirige le trafic vers une image existante : cela prend quelques secondes au lieu d’un build complet. Les migrations de base de données ne sont pas annulées automatiquement, veillez donc à ce qu’elles restent rétrocompatibles.