Il est temps pour les NetOps d’adopter le déploiement continu

Lori Mac VittieIngénieur émérite et évangéliste en chef | F5

Le déploiement continu ne signifie pas nécessairement déployer chaque modification, systématiquement et immédiatement. Mais il faut bien commencer quelque part.

La CI/CD (intégration continue/livraison continue) relève du domaine des développeurs. Il s’agit du modèle global visant à accélérer la livraison — ce qui signifie en réalité « prêt pour le déploiement » pour ceux qui ont l’habitude de l’envisager dans un contexte plus actif et axé sur l’utilisateur.

Cela ne signifie pas que les équipes NetOps peuvent faire abstraction du CI/CD. Bien au contraire. Mais cela ne signifie pas non plus qu’elles doivent maintenir un ratio de 1:1 entre déploiements et livraisons. La fréquence à laquelle les applications sont « prêtes à être déployées », surtout si vos développeurs d’applications maîtrisent parfaitement l’art de la livraison continue, peut être difficile à suivre, en particulier si les équipes NetOps ne maîtrisent pas encore tout à fait l’art du déploiement continu. Il est toutefois possible d’augmenter la fréquence des déploiements, au point que, dans certains cas, les développeurs et l’entreprise auront véritablement l’impression de bénéficier d’un déploiement continu.

Le secret réside dans la distinction entre les « modifications mineures » et les « modifications majeures » apportées à une application.

L’enquête NetDevOps de l’automne 2016 a révélé que les changements mineurs étaient mis en production bien plus fréquemment qu’on ne le laisse souvent entendre. Près de 51 % des personnes interrogées mettent en production des changements mineurs plus d’une fois par jour. Plus d’une personne sur trois mettait en production des changements majeurs entre une et cinq fois par mois, tandis qu’un autre tiers reconnaissait en effectuer moins d’une fois par mois.

Malheureusement, la définition des changements « majeurs » et « mineurs » n’est pas quantifiée, mais comme souvent, ces qualificatifs relatifs sont généralement propres non seulement à un secteur ou à une organisation, mais aussi, bien souvent, à chaque application. Il semble néanmoins qu’un nombre important d’entreprises — un peu plus de la moitié — déploient très régulièrement des changements majeurs en production.

Cela signifie que, globalement, nous avançons à petits pas vers le déploiement continu. Le fait est que déployer une toute nouvelle application n’est pas la même chose que déployer des mises à jour d’une application existante. Même si nous ajoutons de nouveaux services réseau ou applicatifs, le « potentiel de perturbation » reste très différent de celui associé au déploiement d’une application entièrement nouvelle.

Disons donc que, pour l’instant, les toutes nouvelles applications vont nécessiter davantage de coordination et de planification. Il reste néanmoins la grande majorité des applications en production, qui peuvent potentiellement faire l’objet d’un déploiement continu. Pour favoriser cette pratique, nous pouvons notamment contextualiser la distinction entre les changements « mineurs » et « majeurs » en fonction de leur impact sur les environnements de production.

Les changements mineurs pourraient se limiter à ceux qui affectent le fonctionnement interne de l’application. Des changements de logique, par exemple. Ils pourraient inclure des correctifs ou des mises à niveau de la pile applicative (serveur web, serveur d’applications, etc.), ainsi que de l’infrastructure applicative qui la prend en charge. En résumé, les changements mineurs affectent uniquement l’application. Ils ne nécessitent aucune modification du réseau ni des services applicatifs qui assurent concrètement la mise à disposition et la sécurisation de cette application dans le cadre de son utilisation habituelle.

Les changements majeurs seraient donc ceux qui affectent un élément quelconque du réseau ou des services applicatifs prenant en charge l’application. Ils peuvent nécessiter des ajustements de la politique de diffusion (activez donc la compression !) ou l’ajout d’un nouveau service, tel que le filtrage des URL ou l’inspection des requêtes, afin d’empêcher l’exploitation d’une vulnérabilité récemment découverte. Ces changements sont considérés comme majeurs, car ils affectent un ensemble plus vaste de systèmes de production, lesquels peuvent à leur tour avoir ou non une incidence sur d’autres applications.

Vous pourriez même élaborer un système de notation plus nuancé qui tienne compte de l’impact sur les services externes. Un nouveau service est susceptible d’être plus perturbateur qu’un ajustement apporté à un service existant. La mise en œuvre d’une nouvelle politique exige davantage d’attention que celle d’une politique existante faisant l’objet d’une mise à jour mineure.

Une fois que vous vous êtes mis d’accord sur le « système » à utiliser, il devient beaucoup plus facile de convenir d’autoriser les modifications mineures à la demande. En substance, vous passez au déploiement continu en permettant aux applications d’être mises en production tant que leur impact potentiel est considéré comme minime en cas de problème. Modifications mineures, risque mineur. C’est du moins l’hypothèse de départ.

Cela permet de mettre plus rapidement entre les mains des utilisateurs des changements techniques mineurs qui pourraient avoir des répercussions commerciales majeures. En effet, ces changements sont souvent retardés dans les grandes organisations traditionnelles. Même une petite modification de l’interface utilisateur peut être repoussée de plusieurs semaines, voire davantage, en raison de conflits de calendrier et de décisions prises par les comités de contrôle des changements en fonction des priorités des projets ou de considérations politiques. Et ce, même si cette petite modification peut améliorer l’expérience utilisateur et ainsi accroître les taux de conversion ou de fidélisation des clients. Si cette petite modification concerne uniquement l’application, c’est-à-dire s’il s’agit d’un changement « mineur », les considérations politiques du service informatique justifient-elles vraiment de la retarder ?

Le déploiement continu ne consiste pas seulement, sur le plan technique, à permettre des mises en production automatisées ; il s’agit aussi de démanteler les structures traditionnelles qui ralentissent les processus déterminant quand les applications et les mises à jour sont déployées en production (c’est une question de culture).

En établissant des critères communs permettant de distinguer les mises à jour « mineures » des mises à jour « majeures », c’est-à-dire celles susceptibles d’avoir un impact sur des systèmes extérieurs à l’application de celles qui ne le sont pas, les organisations peuvent mettre en place le déploiement continu pour certaines modifications sans accroître les risques ni déstabiliser l’environnement de production. Cela pourrait même avoir un impact positif sur l’activité, auquel cas tout le monde y gagne.

À propos de l’auteur

Lori Mac VittieIngénieur émérite et évangéliste en chef | F5

Lori MacVittie est ingénieure émérite et évangéliste en chef au sein du bureau du directeur technique de F5. Elle possède une expertise approfondie dans la fourniture d’applications, les stratégies d’automatisation et les infrastructures. Elle est réputée pour sa capacité à rendre la complexité intelligible, qu’elle définisse des garde-fous pour les agents d’IA, analyse des architectures multicloud fragiles ou explore les limites des systèmes évolutifs. Elle cumule plus de trente ans d’expérience dans le secteur, couvrant le développement d’applications, l’architecture informatique ainsi que l’exploitation des réseaux et des systèmes. Avant de rejoindre F5, elle a été rédactrice spécialisée dans les technologies et a reçu plusieurs distinctions. MacVittie est titulaire d’un master en informatique et est une autrice prolifique dont les publications couvrent la sécurité, le cloud et l’architecture d’entreprise. Elle est également une passionnée de jeux de société et de jeux vidéo, et assume pleinement ses avis bien tranchés sur le fromage.

Autres articles de Lori Mac Vittie