Transition fluide de la conception à l’exécution
Dans nos blogs précédents, nous avons abordé le Continuous Delivery flow. Cette méthode englobe tous les éléments pour aboutir à la phase de production de manière itérative et sécurisée et dans des délais brefs. Au moment de la transition, la même équipe reste responsable des opérations. C’est un principe clé de l’attitude DevOps : you build it, you run it. La création et la maintenance d’un logiciel s’inscrivent dans une continuité où seules les règles du jeu changent.
L’organisation de la NASA peut illustrer ce point. L’agence spatiale américaine distingue les équipes launch control et mission control, la première étant responsable des opérations jusqu’au moment où le compte à rebours arrive à 0 et où les réacteurs de la fusée s’allument. Jusqu’à cet instant, tout peut être annulé – comme dans un pipeline Continuous Delivery, avec des points de contrôle intégrés et la possibilité d’interrompre la procédure si les exigences de base ne sont pas respectées. Mais une fois la fusée lancée, mission control prend le relais, car il n’est évidemment plus possible de rappeler la fusée en plein vol. Tous les paramètres sont étroitement surveillés et en cas de problème, mission control peut s’efforcer de limiter les dégâts. Là encore, c’est un peu comme la mise en production d’un logiciel : une fois qu’il est lancé et que les utilisateurs y ont accès, il n’est pas facile de revenir en arrière. Mais heureusement, à la différence du secteur aérospatial, il existe des stratégies qui permettent de garder un certain contrôle.
-01.png)
Stratégies de déploiement pour garder un maximum de contrôle
Si l’on part du principe qu’il est possible de distinguer le déploiement d’une nouvelle version et le déploiement de certaines fonctionnalités, c’est tout un monde de possibilités qui s’ouvre. De fait, il y a déploiement (« deploy ») et déploiement (« release ») : d’un côté, la mise en production de nouvelles fonctions binaires – une série de fichiers exécutables dédiés à un certain processus – et de l’autre, une modification des fonctionnalités. Trop souvent, les deux types de déploiement sont soumis au même traitement. Les stratégies suivantes vous permettront de mieux garder le contrôle :
- Déploiement bleu/vert : une nouvelle version est publiée en parallèle à l’ancienne version. Un groupe pilote composé d’utilisateurs volontaires a accès à la nouvelle version afin que celle-ci puisse être testée dans un environnement de production. Si tout se passe bien, tout le monde peut être basculé sur la nouvelle version.
- Déploiement canari : cette stratégie doit son nom aux canaris qui devaient autrefois avertir les travailleurs dans les mines d’une fuite de gaz. Là encore, deux versions du logiciel coexistent et 10 % des utilisateurs sélectionnés de manière aléatoire reçoivent un aperçu de la nouvelle version par un mécanisme de répartition des charges. Ce pourcentage augmente progressivement et si un problème se présente, il est de nouveau réduit.
- Feature flags : de nouvelles fonctionnalités sont disponibles dans le code, mais elles ne sont pas encore visibles pour les utilisateurs. Cela permet de mener des tests en production. Il est même envisageable de laisser les utilisateurs choisir leur version de la fonctionnalité, par la fameuse proposition : « voulez-vous tester la version bêta ? ». Sur cette base, il est d’ailleurs plus facile d’intégrer des systèmes autorégulateurs. Par exemple, si le système de surveillance détecte un problème avec la nouvelle fonctionnalité à partir de l’activation d’un feature flag donné, ce feature flag peut être automatiquement désactivé.
