Le développement des logiciels et applications en agile est de plus en plus demandé actuellement chez des nombreuses entreprises et équipes, vu les différents avantages qui présente cette approche incrémentale et itérative, mais les évolutions et demandes réalisées doivent être livrées d'une manière continue comme j'ai déjà expliqué dans mon article de pratiques "Déploiement Continu" et "Livraison Continue".
De ce fait, il faut bien choisir les bonnes pratiques DevOps de déploiement continu permettant de réduire les risques, maximiser les performances, et éviter les Downtimes (Temps d'arrêt du système durant les mises en production). et parmi les bonnes pratiques DevOps déployées chez plusieurs équipes agiles on trouve : "Canary Release", "Blue-Green", et "Feature Flags" qui sont l'objectif de cet article.
Le déploiement en mode "Blue-Green" :
Cette pratique nécessite la présence de deux serveurs de production identiques et similaires, le premier (Blue) est actif, par contre le deuxième (Green) est inactif. En cas de besoin d'un nouveau déploiement d'une version alors on va le faire sur le serveur inactif (Green), et si tout ce passe bien comme attendu (après avoir passé les différents cas et types de tests en production) alors le serveur inactif (Green) devient actif et vice-versa, comme ça on évite les Downtimes d'une part, et on peut basculer immédiatement vers le serveur inactif pour le rendre actif si le dernier déploiement a provoqué des bugs et des problèmes.
Le déploiement "Canary Release" :
Le mode de fonctionnement de cette pratique est assez similaire au Blue-Green, mais la différence c'est qu'on va ajouter une étape intermédiaire au niveau du serveur qui porte la nouvelle version (serveur inactif) permettant de choisir une catégorie précise et limitée des utilisateurs finaux qui vont tester les nouvelles fonctionnalités déployées. Une fois c'est fait, on peut récupérer les Feedbacks de la catégorie des utilisateurs finaux concernés, et effectuer les corrections et rectifications nécessaires avant de mettre la version concernée en production et rendre le serveur associé actif.
Le déploiement "Feature Flags" :
Cette pratique touche directement les fonctionnalités développées, en mettant un Flag sur chacune au niveau du code. Ce Flag va permettre d'activer ou désactiver une fonctionnalité via son Flag, comme ça celles désactivées seront automatiquement non disponibles et visibles lors de déploiement. Si une fonctionnalité déclenche un bug ou blocage alors il suffit que désactiver son Flag sans avoir besoin à toucher au code source associé.Aussi bien on n'aura besoin de faire un retour arrière (Rollback) pour revenir à la version précédente.
Conclusion :
Chaque projet a ses propres exigences et environnement de travail, c'est pour cette raison qu'il faut bien penser et réfléchir à l'avance avant de choisir et adopter une pratique DevOps de déploiement continu.
Le principe majeur de la plupart de pratiques DevOps et déploiement continu c'est l'automatisation du circuit de développement et réalisation y compris la phase de tests, malheureusement on se confronte parfois à des freins budgétaires qui ignore cette partie et la rend manuelle, par conséquent on perd énormément en terme de performance, sécurité, et fiabilité.
Comments