="http://www.w3.org/2000/svg" viewBox="0 0 512 512">

Gestion de Projet

Mouvement DevOps

Le mouvement DevOps a pris naissance dans le monde de l’édition logicielle. NetDevOps, parfois nommé NetOps, est une transposition de ce modèle dans le monde du réseau. Le rapprochement entre les équipes de développement et d’exploitation, ayant des objectifs différents pour ne pas dire antinomiques, au sein d’une même équipe est un concept qui se marie bien avec le modèle Agile et traduit des éléments qui y ont été abordés.

Ce mouvement met en valeur les notions d’Intégration Continue ou « Continuous Integration » (CI), de Livraison Continue ou « Continuous Delivery » (CD) et de Déploiement Continu ou « Continuous Deployment » (CD).  L’Intégration Continue consiste à mettre en place une plateforme sur laquelle les modifications sont poussées et soumises à des jeux de tests unitaires afin d’être packagées dans un référentiel central utilisé pour le déploiement sur l’ensemble des environnements. Cette plateforme offre l’avantage de proposer un contexte standardisé et beaucoup plus neutre que les postes de travail personnalisés de chaque développeur sur lesquels il pourrait exister des contournement des règles de base de qualité et avec lesquels on ne pourrait pas garantir la répétabilité des processus. Le principe de l’Intégration continue induit que l’application est, à tout moment, potentiellement livrable, mais elle ne peut pas passer en production sans l’aval des équipes opérationnelles. La différence entre la Livraison Continue et le Déploiement Continu se situe uniquement sur le fait qu’après la Livraison une approbation manuelle est nécessaire pour passer en Déploiement, alors que lorsqu’on parle de Déploiement Continu c’est que la mise en production est automatisée. Dans les deux cas, l’objectif est la mise en production sans incident ni régression. C’est à ce stade que les tests d’acceptation sont nécessaires, avant mise en production, afin de garantir le bon fonctionnement de l’ensemble d’un point de vu utilisateur final.

On retrouve les notions de tests TDD, ATDD et BDD évoqués lors de l’étude du modèle Agile. Dans l’organisation CI/CD, il apparait encore plus évident que ces tests se doivent d’être automatisés, et que les déploiements se doivent d’être accélérés et fiabilisés également par des méthodes d’automatisation. Le principe d’automatisation peut commencer dès l’ouverture des cartons des matériels neufs grâce à la fonction appelée « Zero Touch Provisioning » (ZTP), qui permet de charger une configuration, pouvant être personnalisée par équipement, sans même avoir besoin de saisir une configuration minimum.

Si le monde applicatif s’est très largement structuré pour travailler de manière à aller vers une organisation CI/CD, il n’en est pas de même du domaine qui nous intéresse. Il existe, pourtant, de nombreux outils pouvant être utilisés pour mettre en application ces notions dans le monde des réseaux. Il n’est pas question de chercher à reproduire les mêmes fonctionnements que ceux mis en place dans le monde applicatif, mais plutôt de chercher à s’inspirer de ces concepts pour automatiser et professionnaliser tout ou partie du travail à effectuer lors de la conception et du déploiement d’un réseau.

Aujourd’hui, il est possible de mettre en place ces concepts lors d’une phase maquette durant laquelle, le réseau est implémenté progressivement avec l’ensemble des matériels définitifs déconnectés du réseau en exploitation. C’est une fois basculé en exploitation, que les choses se complique un peu. Idéalement, il faudrait posséder une reproduction exacte du réseau sur laquelle l’intégration continue pourrait s’effectuer. Rares sont les clients qui se donnent les moyens de posséder un réseau en double. L’utilisation de simulateurs réseau, ne permet pas encore de reproduire tous les types de constructeurs et tous les types de fonctionnalités nécessaires. L’apport de la virtualisation sous toutes ses formes et de l’avancé des logiciels dans le monde des réseaux avec les éléments constitutifs du « Software Defined Network » (SDN) et du « Network Functions Virtualization » (NFV), laisse présager des améliorations qui permettent de penser qu’il sera possible, rapidement, de mettre en place beaucoup plus facilement les processus nécessaires. Pour le moment, c’est sur un incubateur physique (reproduction du réseau en miniature) qu’un aspect de l’intégration continue peut s’effectuer, ne serait-ce que sous la forme d’une automatisation et de gestion de versions, tout en mettant en place des processus de bascule des configurations en exploitation, une fois validées en incubation.

Commentaires/Errata

Les commentaires sont clos.