Il est temps pour NetOps d'adopter le déploiement continu

Un déploiement continu ne signifie pas nécessairement que chaque changement doit être effectué à chaque fois et immédiatement. Mais il faut bien commencer quelque part.

CI/CD (Continuous Integration/Continuous Delivery) est le domaine des développeurs. Il s’agit du modèle global permettant d’améliorer la vitesse de livraison, ce qui signifie en réalité « prêt à être déployé » pour ceux qui sont habitués à le voir dans un contexte plus actif et lié à l’utilisateur.

Cela ne signifie pas que NetOps peut ignorer le CI/CD. Au contraire. Mais cela ne signifie pas non plus que NetOps doit maintenir un ratio de déploiement/livraison de 1:1. La fréquence à laquelle les applications sont « prêtes à être déployées », en particulier si vos développeurs d'applications ont perfectionné l'art de la livraison continue, peut être écrasante, en particulier si NetOps n'a pas encore perfectionné l'art du déploiement continu.  Mais il est possible d’adapter la fréquence de déploiement à une plus grande échelle, ce qui, dans certains cas, ressemblera certainement à un déploiement continu pour les développeurs et l’entreprise. 

Le secret réside dans la différence entre les « changements mineurs » et les « changements majeurs » apportés à une application.

L' enquête NetDevOps de l'automne 2016 a révélé que des modifications mineures étaient introduites en production avec une fréquence bien plus élevée qu'on ne le croit souvent. Près de 51 % des répondants introduisent des modifications mineures dans la production plus d’une fois par jour. Plus d'un sur trois a apporté des changements majeurs entre 1 et 5 par mois, et un autre tiers a avoué avoir apporté des changements majeurs moins d'une fois par mois.

Malheureusement, la définition des changements « majeurs » et « mineurs » n’est pas quantifiée, mais comme c’est généralement le cas, ces descripteurs relatifs sont souvent propres non seulement à un secteur ou à une organisation, mais souvent à chaque application. Il semble néanmoins qu’un bon nombre d’entre eux – un peu plus de la moitié – déploient des changements majeurs dans leur production de manière très régulière.

Ce qui signifie que dans le grand schéma des choses, nous faisons de petits pas vers un déploiement continu. Le problème est que déployer une nouvelle application brillante n’est pas la même chose que déployer des mises à jour sur une application existante. Même si nous ajoutons de nouveaux services réseau ou d’application, cela reste très différent, en termes de « potentiel de perturbation », du déploiement d’une toute nouvelle application.

Alors disons pour l'instant que les nouvelles applications brillantes nécessiteront davantage de coordination et de planification. Il nous reste certainement la majorité des applications en production comme cibles potentielles pour un déploiement continu. L’une des choses que nous pouvons faire pour encourager cela est de mettre en contexte les changements « mineurs » et « majeurs » par rapport à leur impact sur les environnements de production.

Les modifications mineures peuvent être limitées à celles qui ont un impact sur l'application, en interne. Des changements de logique, par exemple. Ils peuvent inclure des correctifs ou des mises à niveau de la pile d'applications (serveur Web, serveur d'applications, etc.) ainsi que ceux de l'infrastructure d'applications de support. En principe, les modifications mineures n'ont d'impact que sur l'application. Elles ne nécessitent aucune modification du réseau ou des services d'application qui fournissent et sécurisent réellement cette application dans son utilisation normale.

Les changements majeurs sont donc ceux qui ont un impact sur le réseau ou les services d'application prenant en charge l'application. Les changements majeurs peuvent nécessiter des ajustements à une politique de livraison (activer la compression, voulez-vous ?) ou l'insertion d'un nouveau service, tel que le filtrage d'URL ou l'inspection des requêtes pour empêcher l'exploitation d'une vulnérabilité récemment découverte. Il s’agit de changements majeurs dans la mesure où ils impactent un ensemble plus large de systèmes de production qui peuvent ou non, à leur tour, impacter d’autres applications.

Il se pourrait même que vous élaboriez un système de notation plus nuancé qui prenne en compte l’impact sur les services externes. Un nouveau service est probablement plus perturbateur qu’une modification d’un service existant. Une nouvelle politique nécessite plus d’attention lors de sa mise en œuvre qu’une politique existante avec une petite mise à jour.

Une fois que vous avez convenu du « système » que vous allez utiliser, il devient beaucoup plus facile d’accepter d’autoriser des modifications mineures à la demande. Essentiellement, vous passez à un déploiement continu en permettant à la livraison des applications de se dérouler en production à condition que l'impact potentiel soit considéré comme minimal en cas de problème. Des changements mineurs, des risques mineurs. C'est du moins ce que l'on suppose.

Cela permet aux utilisateurs de bénéficier plus rapidement de modifications techniques mineures qui pourraient s’avérer être des changements commerciaux majeurs. Parce que ces derniers sont souvent bloqués dans les grandes organisations traditionnelles. Même un petit changement dans l’interface utilisateur peut être retardé pendant des semaines, voire plus, en raison de conflits de planification et de décisions prises par les comités de contrôle des modifications en fonction des priorités du projet ou de la politique. Même si ce petit changement peut représenter une meilleure expérience utilisateur qui se traduit par des taux de conversion ou de fidélisation des clients plus élevés. Si ce petit changement n’impacte que l’application , c’est-à-dire qu’il s’agit d’un changement « mineur », la politique informatique est-elle vraiment une raison pour le retarder ?

Le déploiement continu ne consiste pas seulement à permettre techniquement des mises en production automatisées, il s’agit également de détruire les constructions traditionnelles qui bloquent les processus déterminant le moment où les applications et les mises à jour arrivent en production (c’est la culture).

En établissant des critères communs pour différencier les mises à jour « mineures » et « majeures », entre celles qui ont le potentiel d'impacter les systèmes extérieurs à l'application et celles qui n'en ont pas, les organisations peuvent permettre un déploiement continu de certains changements sans encourir de risque supplémentaire ni déstabiliser la production. Et cela pourrait bien avoir un impact positif sur l’entreprise, ce qui signifie que tout le monde y gagne.