L’approche DevOps, levier d’une digital factory

DevOps, votre Sherpa vers l’âge moderne de l’IT

Le concept est simple: aligner les pratiques Dev et Ops pour assurer une continuité du développement des déploiements. Si l’on lit entre les lignes, cela signifie ouvrir les silos et se focaliser sur la livraison de valeur. Le fond du problème réside alors en deux questions fondamentales. Comment répartir les rôles et responsabilités de manière pragmatique dans une structure hiérarchisée? Quels sont les choix d’outils, d’implémentation, d’intégration, en bref quelle est sa meilleure ‘toolchain DevOps’ et quels bénéfices métiers en tirer?

En s’appuyant sur l’exemple du DevOps, nous allons proposer des pistes pour faire ses propres choix, et ensuite généraliser l’approche «XOps» à d’autres sujets, car il s’agit d’une bonne pratique à implémenter et qui est bénéfique pour tous.

Saupoudrer de l’agilité dans une structure rigide et hiérarchisée

Le premier challenge dans l’implémentation d’une approche DevOps réside dans le conflit entre l’agilité inhérente à l’approche et la structure traditionnellement en place. Pourtant, si l’on adopte une approche pragmatique, en étendant les rôles traditionnels aux responsabilités dans une chaîne DevOps, il est possible de retirer des bénéfices tout en respectant une structure hiérarchisée.

La clé est de bien répartir les rôles et responsabilités dans les différentes équipes: une première de support DevOps pour implémenter et maintenir la toolchain, une deuxième orientée ‘Release et Ops’ pour garantir les déploiements et le fonctionnement des couches infrastructure et plateforme, et une dernière de développement garantissant également la qualité du code.

Le second défi est d’automatiser un maximum pour garantir le niveau de qualité et de déterminisme dans les déploiements. Fini le classique «cela fonctionnait pourtant sur mon poste». Pour cela, il est primordial de bien penser sa toolchain, et d’y intégrer un maximum d’éléments, infrastructure as code et testing automatisé au minimum, comme expliqué ci-après.

Ne pas penser toolchain, mais plateforme

Il s’agit tout d’abord de penser la «DevOps toolchain» de manière stratégique, dans le contexte actuel des développements et de son infrastructure, mais également de leurs évolutions respectives. Un langage propriétaire amènera d’autres choix qu’une approche plus ouverte.

La subtilité de l’approche vient surtout des aspects infrastructures. Selon que la cible soit ‘on-premises’ uniquement ou multi-cloud, le choix sera différent. La plateforme DevOps faisant partie intégrante de l’écosystème IT de manière pérenne, autant choisir une plateforme adaptée mais évolutive dès le départ et éviter une migration ultérieure.

Un client principalement .Net déployant sur ses propres serveurs ira naturellement vers Visual Studio Azure DevOps Services. Ce qui lui assurera un potentiel déploiement vers le cloud Azure. Cependant, si un déploiement vers d’autres environnements cloud est une éventualité, il conviendra alors de réfléchir à une approche plus agnostique.

Un client développant sous Java vers IBM Websphere pourra considérer une approche Git+Jenkins+Nexus pour son environnement actuel. Et s’il souhaite évoluer vers un déploiement containerisé vers Openshift, il lui suffira de déployer les plug-ins nécessaires. S’il veut s’orienter vers un cloud provider, selon le service choisi, il conviendra alors d’inclure des technologies type Ansible ou Terraform.

Le choix est vaste et il convient d’être bien renseigné ou accompagné. Il en va de même concernant l’inclusion de tests automatisés. Exécuter des tests unitaires en phase de développement ou de build est courant, mais inclure des ‘quality gates’ automatisées l’est moins. Pourtant, le rapport coûts/bénéfices est intéressant.

Pour résumer

Un profil Dev sera responsable du développement du logiciel, mais également de sa partie de tests automatisés, ainsi que de l’alignement avec un profil Ops pour externaliser ses éléments de configuration applicative et ses dépendances à l’environnement cible.

Un profil Ops sera responsable de la réalisation des fichiers de configuration des déploiements, de s’assurer de leur complétude par rapport à l’environnement et de les maintenir à disposition dans les outils.

Un profil DevOps sera quant à lui responsable du bon fonctionnement, mais également de l’évolution de la chaîne DevOps, en s’alignant avec les autres profils technologiques, mais également de manière stratégique pour anticiper les évolutions d’environnements.

Un profil testeur sera quant à lui responsable de l’analyse des résultats de tests automatisés et du développement no-code des tests utilisateurs si un tel outil est disponible.

Cette approche permet de découpler les tests liés à l’infrastructure, à la qualité du code et à l’adéquation du produit livré aux besoins fonctionnels. De plus, l’approche se fondant sur l’automatisation des tâches, le gain de temps et l’augmentation de la fréquence des déploiements viennent s’ajouter aux bénéfices de qualité.

Extension XOps

Les déploiements de modèles d’analyse de données (ModelOps), de chaînes d’extractions de données (DataOps) et cloud se sont inspirées de cette séparation de rôles/responsabilités et du principe d’automatisation pour améliorer ces disciplines.

Ces bonnes pratiques permettent aux départements concernés d’en retirer les bénéfices, et surtout de transformer le risque d’introduire de l’agilité dans une structure hiérarchisée en une opportunité de mieux structurer. L’architecture de ces chaînes XOps et le choix des outils n’en restant pas moins fondamental. Cerise sur le gâteau: intégrer tout ou partie de ces approches permet de supprimer les barrières entre les silos d’une entreprise, de fortement accroître la collaboration entre les équipes et, à l’échelle de l’entreprise, d’entrer dans le monde du DigitalOps où l’énergie est centralisée et focalisée vers la livraison de valeur pour le client final.

Retrouvez l'article sur LG en cliquant ici.