Introduction

Je vais parler du Yaml, mais pas uniquement. Je compte surtout partager avec vous mon expérience avec ce langage et également des expériences qui m'ont permis d'aller toujours plus loin dans la philosophie Dev OPS (un peu comme les niveaux d'appropriation de l'architecture REST pour ceux qui connaissent).

La petite histoire

Comme je l'ai indiqué en préambule, lorsque j'ai découvert le yaml, j'ignorai tout de ce dernier. Il a fallut que je me retrouve dans un contexte avec la nécessité de déployer l'équivalent de 20 sites web, chacun répartis sur 2 à 10 machines. Je vous laisse imaginer le travail que cela représente de faire un déploiement de ce genre à la main... De ce fait l'entreprise en question à décider d'industrialiser ce processus en optant pour du antsible car il a la souplesse d'intégrer des technologies de natures différentes pour les déploiements (écosystème linux ou windows n'a pas d'importance) a cette époque ce logiciel Open Source était alors un choix naturel pour cette entreprise.

Etant dans une équipe orienté Microsoft (Et oui, je fais du dotnet....) le choix d'antsible ne me fut pas très naturel. Mais avec la force des choses j'ai découvert comment mettre en oeuvre ce genre d'outil et les points sur lesquels il faut faire attention. Par le passé j'avais déjà mis en place de la CI/CD en place mais pas à cette échelle, de ce fait, j'avais quelque a priori et ma ma vision était un peu faussée... Mais cette expérience a permis de recadrer cela, et me remettre finalement dans le bon chemin.

Pour résumer: selon l'échelle du projet / solution, il ne faut pas gèrer les choses de la même façon c'est un fait. Or sur internet, toutes les informations que l'on trouve ne spécifie pas la notion d'échelle ce qui rend difficile l'appropriation des processus ou changement de méthodes. Lors de la réalisation de vos pipelines ou mise en place d'une nouvelle organisation, vous pouvez être influencé par les gros acteurs sans forcément savoir que ce sont des gros acteurs. Or si vous projet est très modeste, vous pourriez avoir un goût amer, après avoir passer beaucoup de temps pour effectuer les changements de processus. Car vous avez obtenu un flux qui fonctionne certes, mais pas aussi bien que vous l'auriez imaginé...

 

Avec ce type d'industrialisation une fois que les processus ont été mis en place, l'avantage c'est qu'un seul clic permet d'effectuer tout le déploiement. Et c'est répétable à l'infini. Alors qu'à la main, c'est long et souvent à force de répéter et bien l'être humain fini par faire des erreurs... Ce qui engendre un délais supplémentaire pour vérifier que tout soit opérationnel aprés déploiement et corriger ce qui a été mal fait. C'est ce qui a confirmé mon opinion à l'époque qu'utiliser des techniques d'industrialisation sont l'avenir du développement logiciel. Et ce quelque soit la taille du projet / solution, ce qui n'est pas simple à expliquer pour des entreprises qui ont une culture assez conservatrice sur leur processus.

C'est quoi le rapport avec le sujet du Yaml ?

Et bien avec antsible nous utilisions Yaml pour décrire l'insfrastructure sous jacente aux déploiements de nos livrables qui ont été généré à partir d'un serveur tfs interne. Yaml servait également à définir les fonctions pouvant être appellés pour effectuer certaines tâches particulière lors du processus de déploiement. C'est ainsi que j'ai fais mes armes avec Yaml. Ce qui ne fut pas simple car un simple espace et s'est le drame avec Yaml, et antsible ne gérait vraiment pas bien les erreurs... Du coup, les phases de débug furent très laborieuse.

Ainsi dans un premier temps, je fus surtout amener à fuir ce langage au lieu de l'apprécier. D'autant qu'avec l'ergonomie de TFS pour effectuer les déploiements je trouvais cela vraiment compliqué pour pas grande chose. Toutefois avec antsible il y a des fonctionnalités native qui ont été mis en place maladroitement sur tfs. Comme la promotion de package par exemple, ou le renommage des  builds ou encore la gestion des versions. Cela vous paraître un détail, mais une personne de l'équipe avait l'habitude de travailler avec un point de vue trés différent du reste des membres de l'équipe et avec le recul à raison. Il n'avait pas d'expérience sur TFS et son contrôle de code source historique, de ce fait les contraintes associés des branches lui était particulièrement inconnu, car lui avait l'habitude de travailler avec git.

Et notamment la gestion des branches est très différente, et permet de raisonner de manière plus logique. On parle bien de version de livrable et non d'environnement. Et oui avec avec TFS, nous avons tendance à associer une branche à un environnement. Ce qui en fait est une absurdité... On n'a pas de souplesse et on amène au contraire du risque à gérer les branche avec du dev, qual, et associé la main à la prod. Mais c'est un autre débat qui fera peut-être l'objet d'un autre billet. 

Bref, il ne faut pas sous estimer l'apport que du "sang frais" peut faire au sein d'une équipe.

Suite de la petite histoire

Oui, la petite histoire est un peu longue et je n'ai pas encore fini de la décrire avant de rentrer plus en matière avec YAML... Mais j'estime que c'est important que vous compreniez mon expérience avec ce langage afin de vous faire partager le fait que c'est un langage qui devient un incontournable dans le monde Dev OPS actuel.

Suite à cette première expérience professionnel avec Yaml, j'ai finalement eu l'opportunité de travailler sur un autre contexte. Je suis amené à travailler le développement d'une plateforme pour le compte de l'état suisse, enfin plus exactement pour le canton de Vaud. Cette plateforme date de 2012, c'est ancien mais finalement pas tant que cela.

Cette plateforme fut à l'époque de sa conception très en avance sur son temps, puisque qu'on peut la résumer  d'un certain point de vue à une plateforme low-code. Bien sur, adapté au contexte dans lequel elle s'inscrit avec l'état, mais elle reprends le principe de pouvoir par paramétrage obtenir les flux métiers voulus. Hélas, le budget pour mettre en place cette plateforme fut très modeste pour ce type de sujet dont l'objectif fut de résoudre certaines problématiques métiers dans l'urgence avant de penser à l'avenir en tant que tel. Or les personnes ayant participées au développement étaient de la "vielle école" ce qui a donnée plein de travers avec une méconnaissance notamment de la POO avec C# et d'un tas de concept d'architecture tout aussi important. Mais ce n'est pas le sujet du billet.

La plateforme était mis à jour régulièrement avec 3 déploiements dans l'année effectué à la main. Il n'était alors pas possible de faire mieux car les risques de régressions étaient trés conséquent et il fallait une période de stabilisation aprés les développements relativement importante environ un à 2 mois pour s'assurer de ne pas introduire trop de probléme suite au déploiement. De ce fait devenant la seule personne en charge des développement, un tel ratio de vérification n'était pas quelque chose de satisfaisant. Et je n'ai jamais adhéré à cette culture de faire les choses à la main (un peu trop feignant pour cela, et surtout j'estime que ma valeur ajoutée est ailleurs). Ainsi après avoir pris mes marques, j'ai vite compris que la philosophie des équipes métiers étaient finalement orienté sur des concepts agile. De ce fait, j'ai proposé de changer les processus de développement qui étaient utilisés avant mon arrivée afin de pouvoir monter la cadence de déploiement et surtout assurer la qualité des livraisons. Car la nouvelle cible était était d'ouvrir la plateforme à plus large échelle à long terme. De ce fait, travailler à la main était surtout un frein à l'évolution. Dans ces circonstances, j'ai mis tous mes moyens de persuasions possible afin que nous puissions mettre en place une plateforme devops server du fait des contraintes de l'état et de la sensibilité des données qui ne permettait pas d'utiliser la version cloud d'azure dev ops.

Mon chef, m'a fait confiance et je l'en remercie beaucoup pour cela. Et il m'en remercie aussi beaucoup en retour car cela a permis de démontrer l'efficacité d'avoir accepter le  changement des anciens processus. Pour résumer, nous sommes passés de 3 livraisons par an à 6. Cela a été rendu possible par deux aspects : 

• l'industrialisation compléte (CI / CD) avec inclusions des tests automatisés
• Ajout d'une nouvelle ressource de développement

C'est vraiment l'un et l'autre qui ont permis de monter en cadence, tout en conservant la maitrise de la qualité voir à l'augmenter.

La mise en place de devops server

A l'époque nous avons mis en place Azure Dev Ops Server 2019 (C'était la plus récente).

Etape 1 : Contrôle de code source

Dans un premier temps nous avons changer le control de code source pour git au lieu de SVN. Je me suis senti beaucoup plus allégé. Je suis passé des années 1950 à l'ère moderne en l'espace d'une journée. Car il faut voir que c'est stressant d'utiliser les anciens outils de contrôle de code source. Ils sont la source de beaucoup d'erreurs alors qu'ils sont censé nous apporté de la productivitè justement. Leur approche n'étant pas parfaite, cela impose de réfléchir d'une façon qui n'est pas fluide pour la gestion du code, notamment des branches. D'ou une source d'anxiété qui ne devrait pas exister. Et c'est ce que permet git justement.

C'est une étape relativement simple, qui prend très peu de temps à l'échelle du développement d'une plateforme. Aussi, ce peut-être un moyen de commencer tout petit dans l'appropriation d'une culture Dev OPS dans votre structure. 

Etape 2 : Gouvernance du projet

L'étape suivante fut de montrer comment on pouvait s'organiser pour travailler sans utiliser Excel pour définir les besoins fonctionnelles. Et oui, même le cahier des charges étaient un mixte entre excel et word... avec la gestion des conflits des mises à jour de fichiers etc. Bref, un enfer collaboratif que dev ops a résolu facilement car c'est l'une des briques de base.

J'ai eu la chance que mon chef a donné toute sa confiance dans ma démarche car il n'était pas réfractaire au changement bien au contraire. Cela a pris du temps, car moi-même je n'avais pas l'habitude de ce type d'analyse. Je n'ai jamais eu à prendre la place d'un MOA ou business analyst dans mes anciennes expériences. Toutefois, ce fut trés enrichissant, et cela m'a permis de murir sur l'usage de la plateforme afin de l'aborder confortablement et ce peu importe les interlocuteurs. Alors oui, notre vision initiale ne fut pas la meilleure, mais en soit c'est le propre des méthodes Agile, et de plus mon chef a la même vision que moi : l'amélioration continue. De ce fait, on a réajusté et à présent cela fonctionne plutôt bien.

Itération par Itération nous avons fait évoluer notre méthodologie pour l'adapter à notre taille de notre équipe et aux processus en liens avec les équipes métiers, notre vocabulaire, nos attentes. La difficulté principale dans la gouvernance d'un projet ou plateforme est de s'assurer que tout le monde partage une vision commune des processus en oeuvre de leurs avantages et inconvénients. Notamment, nous avons tous des expériences différentes ce qui fait que nous avons tous un point de vue différent.

Toutefois pour s'organiser convenablement, il faut parvenir à un consensus afin que tout le monde puisse s'y retrouver. Trouver ce consensus ce fut quelque chose d'assez nouveau car ce n'est pas dans la culture Française. La recherche du consensus est très ancré dans la culture Suisse, et sur ma précedente mission l'entreprise appartenait à des italiens et l'équipe était constitué quasiment que de Français... Du coup, je n'avais pas eu cette perception à mon arrivée en Suisse.

Bref, pour revenir à dev ops, le code source étant intégrer à la plateforme cela permet de pouvoir organiser le travail en lien avec la gouvernance. Cela permet alors de passer à l'étape 3.

Etape 3 : Amélioration des processus de déploiements génération des livrables.

En fait, cette étape peut-être effectué en parallèle de la mise en place de la gouvernance. Elle dépend surtout de l'étape 1. Quoiqu'il en soit, j'ai commencé à mettre en oeuvre un peu de nettoyage sur les processus pour déployer la plateforme en utilisant des processus CI / CD de Dev OPS. Au début, mon chef fut septique mais m'a malgré tout laisser faire pour mieux se rendre compte de la valeur ajoutée. Et il a été particulièrement surpris de l'apport qualitatif. Il y avait beaucoup moins d'erreurs lors des mises en production... et surtout cela a diminué le stress car les changements de configuration sont maitrisés assez naturellement avec ce type de processus sans compter sur le retour en arrière qui s'effectue en un clic.

Ce retour en arrière était beaucoup plus stressant avant...

Au fil, du temps j'ai peaufiné les déploiements pour être vraiment en phase avec les changements apportés sur l'étape 2. Comme l'ajout de référence spécifique utiliser au sein de l'entreprise dans le cadre des mises en production.  Puis, j'ai réussi à convaincre mon chef de l'utiliter d'intégrer les tests automatisés. Ce ne fut pas une mince affaire, il était très réfractaire car il avait en tête un cout monstrueux et n'arrivait pas à identifier la valeur ajoutée. Surtout avec un contexte ou nous pourrions avoir à réécrire à zéro la plateforme.

Dans cette démarche, je ne parles pas des tests unitaires. Dans notre cas, cette notion est juste inutilisable car le code est tellement complexe et fortement couplé qu'on ne peut rien testé de manière atomique. Dans ces circonstances, le meilleur moyen fut de simuler le comportement utilisateur afin d'éviter de le faire nous-même pour détecter les régressions.

Vu que nous passions 1 à 2 mois de tests, la valeur ajoutée pour moi était évidente. Mais c'est la volonté d'augmenter le périmétre tout en ayant des composants obsolétes qui si nous ne faisons rien, à long terme il ne sera alors plus possible de maintenir ou faire évoluer la plateforme. Une sorte de tic-tac s'est enclenché dans la tête de mon chef, ce qui m'a permis de fournir des arguments pour le convaincre de la pertinance de l'argument que les travaux de réalisation il y en aura toujours plus, et qu'il faut s'assurer de ne pas introduire de régressions, or le temps nécessaire pour faire les vérifications de non régression n'est compressible avec une méthodologie manuel.

Puis avec l'arrivée du Covid, il a fallut accèlérer dans la mise en place de nouveaux flux métier sur la plateforme, et c'est ce qui a provoqué le besoin de renfort en capacité de développement de l'équipe. Cela a permis de rassurer mon chef dans la capacité à gérer à long terme la plateforme. De ce fait, j'ai pu finir de le convaincre du bien fondé de cette dèmarche des tests automatisés.

Ce fut un peu laborieux à mettre en place effectivement. Afin de vous éviter de tomber dans les même travers : il faut oublier Selenium même si son intégration est de meilleur qualité avec devops au travers des plans de tests, la technologie n'est pas assez stable, ni suffisament sécurisé vu les contraintes qu'elle impose au niveau des droits (Oui il y a peut-être un gros historique dessus, mais comme vous l'avez vu, il faut savoir accepter le changement ;) ).

Je vous conseille plutôt testcafe. Ce fut un premier périmétre de plus de 360 tests que nous avons mis en place. Et dés la préparation de notre première mise en production avec les tests intégrer dans nos flux, nous avons constatés les bien faits de cette démarche en racourcissant la détection et correction des régressions. Cela a fini de convaincre mon chef du bien fondé, d'autant que les déploiements sont alors beaucoup moins stressant car il est acquis que nous couvrons l'application par nos tests.

Avant pour effectuer la stabilisation, il fallait compter entre 1 et 2 mois. Nous sommes passés à 15 jours seulement, sachant que nous n'avons pas encore fini d'introduire tous les tests que nous pouvons automatiser... Donc probablement que nous pourrons encore réduire cette période.  C'est aussi ce qui nous a amenés à augmenter notre cadence de déploiement de de 3 déploiements en production à 6. 

En résumer, mon chef fut agréablement surpris du résultat, et un chef content et bien je suis content ;) d'autant que je suis moins stresser à présent pour faire les déploiements ;). Toutefois, je suis d'accord avec lui : cela nécessite une bonne maturité pour pouvoir déclencher ce type de développement sur les tests automatisés. Si vous n'êtes pas préparés, vous allez vite vous prendre un mur...

Le passage au yaml

Et oui, car le fin mot de l'histoire c'était pour parler du yaml. Je n'ai pas oublié ;). Ce fut ma deuxiéme tentative d'utiliser du yaml. Et cette fois de mon propre désir... Non en réalité ce qui m'a interpellé c'est que Microsoft introduise dans dev ops également ce langage pour effectuer les builds et déploiement. En creusant, je me suis aperçut qu'avec leur implémentation  la peinture n'est pas encore fraîche.  Mais, une chose en ressort, c'est la facilité de maintenance. Car lorsqu'il faut mutualiser les traitements, ou voir les dépendances, sur l'interface c'est très fastidieux (Et pourtant dans notre contexte, le scope est petit). Or tout décrire en yaml facilite la recherche, mais surtout c'est le meilleur moyen pour archiver les processus en lien avec vos développement soit avec la notion des branches.

 

C'est ce travail avec Yaml, qui m'a permis de forcer la migration vers dev ops 2020 et oui 2019  n'est pas compatible avec le fait de créer des processus en yaml. Puis j'ai réussi à convertir à installer dev ops plus en "POC" mais en module transverse dans la structure, vu la différence de culture entre le terrain et le top management ce ne fut pas une mince affaire...

Mais pour revenir au YAML, la montée en version des pipelines s'effectuent sans stress contrairement à l'utilisation des pipelines classique. Du coup, cela m'a permis de voir l'efficacité du langage avec devops. Et cette fois je l'utilise car je souhaite l'utiliser, personne ne m'y a forcé. Et je comprends pourquoi Microsoft l'a introduit. Un retour en arrière sera difficile. C'est avec cette dernière expérience que je constate que finalement rechercher un profil dev ops a surtout du sens pour les équipes qui recherche un apport complémentaire sur l'industrialisation qu'elle ne maitrise pas elle-même afin de gagner en autonomie et surtout améliorer la productivité de l'équipe. Car c'est un travail à faire au quotidien. Mais ce type de profil, peut venir soit par des équipes plus opérationnels, soit des équipes plus orientés développement. En réalité, cela n'a pas d'importance, l'essentiel est de s'assurer que les livrables soient qualitatifs et qu'on puisse en déployer souvent en minimisant le risque.

Du coup, j'ai converti tous nos processus (bon ok, je n'es pas encore fini) en yaml. Et c'est aussi pour cela que je peux dire que la peinture n'est pas fraiche. Il y a des fonctionnalités présentes sur les pipelines classique qui ne sont pas possible en yaml. Par exemple planifier uniquement une phase n'est pas possible pour l'instant avec le yaml, c'est tout le flux que l'on déploit. Du coup, cela force à revoir le découpage des flux. Pour l'instant, je ne saurais pas dire si c'est une bonne chose ou non. Il faut que je continue mes expérimentations.

De même le truc qui manque avec le multi-stagging c'est le déploiement par environnement. on peut juste associer les ressources mais utiliser les pool de déploiements n'est pas possible. Du coup, on a un schéma en YAML qui est entre deux mondes. De même que le tracking entre le déploiement et l'environnement ne suit pas le nom que l'on peut renommer de la build. C'est une notion qui est importante à mes yeux, car il permet d'avoir une communication clair entre toutes les parties prenantes. Ainsi à toutes étapes, nous connaissons la version qui a été déployé grâce à ce renomage. Toutefois, c'est pas un point trés important aujourd'hui vu que nous n'utilisions pas ce tracking jusqu'à présent.

Conclusion

Passez au YAML, au déploiement CI, CD, Aux tests automatisés, oui cela fait peur vu l'effort que cela nécessite pour faire les changements. Mais vous y gagnerez tellement au quotidien : Meilleure qualité des livrables, Livrables déployés plus souvent, et étrangement moins de stress comme quoi augmenter la productivité ne rime pas toujours avec anxiété ;)