Aujourd’hui les utilisateurs ont l’habitude de disposer de services numériques toujours accessibles. Pourtant ces services doivent régulièrement être mises à jour. Certains services internationaux ou critiques doivent fonctionner 24h/24h et pour d’autres le coût de déploiement de nuit (en HNO) reste prohibitif.
Le concept du Zero Downtime Deployment permet d’apporter une réponse efficace à cette problématique.
Le process de déploiement
Le déploiement sans arrêt de service nécessite d’adapter l’ensemble du processus de développement.
Les spécifications doivent être divisées en petit bloc, le code doit être adapté en conséquence et le processus de recette doit être le plus automatisé possible pour gagner en efficacité et réactivé.
Etant donné que l’on va livrer plus souvent des petites modifications, il est important de disposer d’une chaîne CI/CD permettant de livrer de façon automatique.
Le patterns de déploiement
Certains patterns sont reconnus pour leurs efficacités dans le déploiement sans arrêt de service
On utilise les principaux patterns reconnus pour le Zero Downtime Deployment :
- Blue-Green deployment : Deux environnements identiques (Blue et Green) sont maintenus. Seul l’un est actif à la fois. Le déploiement se fait sur l’environnement inactif, puis le trafic est basculé vers celui-ci.
- Canary Release : La nouvelle version est déployée progressivement à un sous-ensemble d’utilisateurs (ou de serveurs), puis étendue si tout va bien.
- A/B Testing : Deux versions coexistent en production, et le trafic est réparti entre elles pour comparer les performances ou l’expérience utilisateur.
- Shadow deployment : La nouvelle version reçoit une copie du trafic en parallèle de la version actuelle, sans impact sur les utilisateurs. Les réponses ne sont pas renvoyées aux clients.
La gestion des sessions
Suivant le pattern utilisé et l’application hébergée la gestion des sessions doit être adaptée pour le ZDD.
Le premier principe est de minimiser le stockage des informations en session au stricte nécessaire.
Ensuite, si l’infrastructure dispose d’un load balancer il est possible de le paramétrer pour que la session d’un utilisateur actif soit redirigé vers le même serveur.
Cela permet d’assurer la cohérence d’exécution au sein de la même version de l’application.
Une autre alternative est de gérer les sessions sur chaque serveur.
Dans ce cas il faudra prendre soin de ne pas ajouter d’incompatibilité au niveau des sessions entre 2 versions de l’application.
La gestion de la base de données
Une autre problématique courante à prendre en considération est la gestion d’une base de données.
Les changements effectués dans la structure des données doivent rester compatible en chaque version.
Pour cela, une pratique consiste à mettre en place un schéma transitoire des données et d’utiliser le pattern Features Toggles dans le code de l’application.
Ainsi un ensemble de variables et de conditions permettent de migrer progressivement les données vers le schéma ciblé avec la possibilité d’effectuer un retour en arrière si nécessaire.
La gestion de l’API
Si l’application dispose d’une API, celle-ci doit permettre une transition entre les différentes versions de l’application.
Une bonne pratique consiste à versionner chaque route de l’API, par exemple au niveau de l’URL.
Ainsi il est possible de continuer à consommer 2 versions d’une même route et de supprimer l’ancienne uniquement quand celle-ci n’est plus utilisée.
Déployer des évolutions sans arrêter une application nécessite d’adapter les processus et les pratiques.
Mais cette transformation permet de répondre aux contraintes d’accessibilité d’une application et de réduire le délai de commercialisation (Time to Market).
Cette démarche s’inscrit parfaitement dans les mouvements Agile et DevOps.
Si vous souhaitez passer au Zero Downtime Deployment venez échanger avec nos tech leads.
