Pourquoi votre stratégie de déploiement dépend du type d'application que vous construisez

Quand vous commencez à développer des logiciels, toutes les applications se ressemblent plus ou moins. Vous écrivez du code, vous l'exécutez, quelqu'un l'utilise. Mais dès que vous devez livrer cette application dans un environnement où des utilisateurs réels en dépendent, vous découvrez rapidement que les applications ont des personnalités très différentes. Et ces différences déterminent tout ce qui concerne leur déploiement.

L'application stateless : simple et remplaçable

Imaginez une API météo. Elle accepte un nom de ville, retourne la température et l'humidité. Chaque requête est indépendante. L'application récupère des données fraîches à chaque fois, ne stocke rien localement et n'a aucune mémoire de qui a demandé quoi.

Ce type d'application est appelé stateless (sans état). Elle ne se soucie pas des requêtes précédentes. Chaque appel est une page blanche.

Les applications stateless sont les plus faciles à déployer. Si une nouvelle version casse quelque chose, vous la remplacez par l'ancienne. Pas de données à gérer, pas de migration à annuler, pas de problèmes de compatibilité. Vous pouvez revenir en arrière en quelques secondes. Vous pouvez les passer à l'échelle horizontalement en exécutant plus d'instances. Vous pouvez tuer des instances sans cérémonie.

Le risque est contenu. Si quelque chose tourne mal, les dégâts se limitent aux requêtes en cours. Personne ne perd de données. Aucune session utilisateur n'est corrompue.

L'application stateful : prudente et complexe

Imaginez maintenant un système de réservation de billets de cinéma. Cette application stocke quelles places sont prises, qui les a achetées et comment elles ont été payées. Chaque transaction modifie l'état du système. La base de données détient la vérité, et le code de l'application doit rester synchronisé avec cette vérité.

C'est une application stateful (avec état). Elle dépend de données persistantes. Et cela change tout en matière de déploiement.

Vous ne pouvez pas simplement échanger les versions. Si la nouvelle version modifie la façon dont elle lit ou écrit les données, le schéma de la base de données doit peut-être migrer en premier. Si la migration s'exécute et que le nouveau code a un bug, le retour en arrière n'est pas simple. L'ancien code pourrait ne pas comprendre le nouveau schéma. Les données ont peut-être déjà été transformées. Vous pourriez devoir restaurer une sauvegarde, ce qui prend du temps et risque de perdre des transactions récentes.

Les applications stateful exigent une séquence minutieuse : migrer la base de données, déployer le nouveau code, vérifier que tout fonctionne et avoir un plan pour le cas contraire. Le rollback est rarement une commande unique. C'est souvent une procédure en plusieurs étapes qui nécessite une coordination.

Le spectre d'impact : outil interne vs service public

Les applications diffèrent également par l'ampleur des dégâts qu'elles peuvent causer en cas de panne.

Considérez un tableau de bord d'administration interne utilisé par cinq personnes dans votre entreprise. S'il tombe en panne pendant dix minutes, quelqu'un pourrait être contrarié, mais personne ne perd d'argent. Le déploiement peut être simple. Vous pouvez vous permettre un certain temps d'arrêt. Vous pouvez pousser des modifications et corriger les problèmes plus tard.

Considérez maintenant une passerelle de paiement ou une page de paiement e-commerce. Des milliers d'utilisateurs l'utilisent chaque seconde. Si elle tombe en panne, les transactions échouent, les utilisateurs se plaignent, les revenus chutent. L'impact est immédiat et mesurable.

Cette différence d'impact détermine le niveau de prudence nécessaire lors du déploiement. Les applications à faible impact peuvent être déployées directement avec un minimum de cérémonie. Les applications à fort impact exigent des déploiements progressifs, une surveillance, des feature flags et un plan de rollback clair. Vous pouvez déployer sur un serveur d'abord, surveiller les erreurs, puis augmenter progressivement le trafic. Vous pouvez exécuter la nouvelle version en parallèle de l'ancienne pendant un certain temps. Vous pouvez utiliser des déploiements canary ou des stratégies blue-green.

Le diagramme suivant vous aide à choisir la stratégie de déploiement adaptée à la nature et au niveau de risque de votre application :

flowchart TD A[Début : Quel type d'application ?] --> B{Stateless ou Stateful ?} B -->|Stateless| C{Niveau d'impact ?} B -->|Stateful| D{Niveau d'impact ?} C -->|Faible| E[Mise à jour progressive simple] C -->|Élevé| F[Blue-green ou canary] D -->|Faible| G[Mise à jour progressive avec plan de migration] D -->|Élevé| H[Déploiement progressif + migration DB + surveillance] E --> I[Rollback rapide par échange] F --> J[Basculement progressif du trafic] G --> K[Tester la procédure de rollback] H --> L[Plan de rollback en plusieurs étapes]

Le niveau de processus doit correspondre au niveau de risque. Toutes les applications n'ont pas besoin d'un pipeline de déploiement de plusieurs heures avec des approbations et des runbooks. Mais celles qui peuvent causer des dégâts réels méritent cette attention.

Les dépendances : le couplage caché

Certaines applications sont autonomes. Elles fonctionnent sans rien d'autre. Vous les déployez, elles fonctionnent.

La plupart des applications ne sont pas comme ça. Elles dépendent de bases de données, d'API externes, de files d'attente de messages ou d'autres services internes. Une nouvelle version de votre application peut reposer sur un nouveau point de terminaison d'une API qui n'a pas encore été mise à jour. Elle peut s'attendre à un format de réponse que l'ancienne API ne fournit pas. Elle peut nécessiter une migration de base de données qui n'a pas été effectuée.

Les dépendances créent un couplage. Lorsque vous déployez une nouvelle version, vous devez vous assurer que tout ce dont elle dépend est disponible et compatible. Il ne s'agit pas seulement de disponibilité. Il s'agit de compatibilité contractuelle. Votre nouveau code peut parfaitement fonctionner en isolation mais échouer en production parce que le schéma de la base de données a changé, la réponse de l'API a changé ou le format du message a changé.

C'est pourquoi l'ordre de déploiement est important. Si votre application dépend d'une base de données, la migration de la base de données vient généralement en premier. Si elle dépend d'un autre service, ce service doit être déployé en premier ou au moins être rétrocompatible. Si vous ne pouvez pas garantir la compatibilité, vous devez concevoir votre déploiement pour gérer à la fois les anciennes et les nouvelles versions en cours d'exécution simultanément.

Ce que cela signifie pour votre pipeline CI/CD

Toutes ces différences — stateless vs stateful, faible impact vs fort impact, indépendant vs dépendant — façonnent la façon dont vous construisez votre pipeline CI/CD.

Il n'existe pas de stratégie de déploiement unique qui fonctionne pour toutes les applications. Un pipeline conçu pour un microservice stateless échouera pour un monolithe stateful. Un processus de déploiement conçu pour un outil interne sera trop risqué pour un système de paiement orienté client. Un plan de rollback qui fonctionne pour une application autonome se brisera pour une application qui dépend d'une base de données migrée.

Votre pipeline doit refléter la nature de l'application qu'il sert. Cela signifie :

  • Les applications stateless peuvent utiliser des pipelines simples avec un rollback rapide.
  • Les applications stateful nécessitent des étapes de migration minutieuses et des procédures de rollback testées.
  • Les applications à fort impact exigent des déploiements progressifs et des points de contrôle de surveillance.
  • Les applications dépendantes nécessitent des vérifications de compatibilité et des déploiements ordonnés.

Checklist pratique pour évaluer les besoins de déploiement de votre application

Avant de concevoir ou d'ajuster votre pipeline de déploiement, parcourez cette liste :

  • L'application stocke-t-elle des données qui doivent survivre aux déploiements ? Si oui, prévoyez des migrations de base de données et des modifications de schéma réversibles.
  • Combien d'utilisateurs sont affectés si l'application tombe en panne ? Si le nombre est important ou l'impact financier élevé, ajoutez des déploiements progressifs et de la surveillance.
  • L'application dépend-elle d'autres services ou bases de données ? Si oui, vérifiez la compatibilité et planifiez l'ordre de déploiement.
  • Pouvez-vous revenir en arrière en échangeant l'ancienne version, ou devez-vous annuler les modifications de données ? Dans ce dernier cas, testez la procédure de rollback avant d'en avoir besoin.
  • L'application peut-elle gérer l'exécution de deux versions en même temps ? Sinon, vous aurez peut-être besoin d'un temps d'arrêt ou d'un modèle de déploiement blue-green.

L'essentiel à retenir

La façon dont vous déployez une application n'est pas déterminée par le langage de programmation, le framework ou l'outil que vous utilisez. Elle est déterminée par la nature de l'application : si elle conserve un état, l'ampleur des dégâts en cas d'échec et ses dépendances. Comprenez d'abord ces trois choses. Ensuite, concevez votre pipeline. Tout le reste n'est qu'un détail d'implémentation.