La confusion de cette discipline

Comme son nom ne l’indique pas très clairement, cette pratique, cette discipline n’est pas une pratique de tests. Bien que possédant le mot test dans son nom, cette pratique vise en premier lieu un tout autre aspect du développement logiciel. Cet aspect est le développement itératif de la fonctionnalité. L’idée principale que je donnerais pour cette pratique est la suivante : « Pour développer une fonctionnalité donnée, nous allons nous concentrer successivement sur des aspects partiels de la fonctionnalité et ainsi augmenter progressivement les capacités de notre logiciel jusqu’à atteindre le développement global de la fonctionnalité« .

L’idée derrière le TDD est la suivante, résoudre un gros problème est souvent difficile, par contre découper ce problème en plus petits problèmes rend la résolution des petits problèmes plus simple, nous gagnons donc en efficacité. Nous retrouvons ici le postulat suivant « plus c’est petit, plus c’est simple« .

Afin d’étayer cette définition encore très abstraite prenons un exemple dans le cadre du développement en TDD outside-in (nous reviendrons plus tard sur les variantes) d’une fonctionnalité de calcul du montant total d’un panier composé de lignes de produits. Les lignes de produits sont elles mêmes composées d’un prix unitaire du produit et de la quantité de ce produit dans le panier.

Découper le problème

Bien que cet exemple soit très simple il va permettre de montrer les principes du TDD. Dans notre exemple, nous allons découper le problème comme cela : le montant total du panier est équivalent à la somme du montant de chaque ligne de produits. Cette première conception semble tout à fait réaliste et semble même assez simple à réaliser, seul problème à ce jour nous n’avons pas le montant de chaque ligne de produits. C’est un des concepts du TDD outside-in on part du besoin depuis l’extérieur du logiciel, on part du comportement que l’on souhaite, ici l’on souhaite pouvoir avoir le montant total du panier et ensuite nous « descendons » dans la hiérarchie des éléments en faisant comme si les moyens à notre disposition étaient déjà présents afin de découper le problème. Ici on part du principe que nous serons capable d’avoir le montant de chaque ligne à l’avenir, on pourra alors facilement réaliser la somme de ces lignes. On répète l’opération de « descente » dans la hiérarchie des éléments jusqu’à répondre entièrement au problème initial.

On voit ici que la conception par découpage du problème, petit pas par petit pas est au coeur du TDD. Mais le TDD amène avec lui d’autres aspects essentiels, la concentration unitaire et le juste nécessaire.

Concentration unitaire

Afin de permettre cette descente dans la hiérarchie de vos éléments, de vos abstractions (ok de vos objets dans de nombreux cas), le Test Driven Development propose de se concentrer sur chacun des aspects partiels de la fonctionnalité de manière unitaire (là vous me voyez venir). La pratique qu’il préconise pour cela est donc la pratique des tests. Encore une fois en partant du postulat plus c’est petit, plus c’est simple, le TDD préconise de ne pas prendre en compte les autres aspects partiels de la fonctionnalité lors de la descente. Pour cela nous allons pratiquer le test automatique en mode « test first » et unitaire. Comment cela se traduit en pratique ?

Les trois étapes du TDD

S’il y a un point qui fait débat sur le TDD, c’est bien celui-ci, certains aiment à dire que le TDD revient à écrire un test avant d’écrire le code source de production, c’est une simplification tout à fait juste mais assez incomplète du processus global initialement proposée par Kent Beck lors de la création de la pratique.

Le Test Driven Development d’un point de vue code se décompose autour de deux éléments, d’une part le code source de production, c’est le code de votre application qui sera exécuté lors de l’accès à votre application notamment en production. D’autre part, le code source de tests, c’est le code qui va lancé le code source de production et vérifier son comportement.

La pratique du TDD se décompose en trois étapes avec pour chacune une couleur associée :

• Écrire du code de tests qui échoue (red)
• Écrire du code de production qui fait passer les tests (green)
• Remanier les deux parties de code source (production et tests) (blue)

Pour détailler ces trois étapes, cela implique qu’avant chaque modification du code de production, je dois écrire un premier test qui démontre que le code source de production actuel ne répond pas à notre aspect partiel, notre cas d’utilisation de la fonctionnalité. Je dois alors avoir un unique test qui échoue afin de me concentrer uniquement sur cet aspect partiel de la fonctionnalité globale. Ensuite seulement je peux réaliser du code de production pour faire passer ce test. Et enfin je remanie mon code source de production et de tests, je ne vais pas détailler ici la pratique de la troisième étape, le refactoring, cette troisième étape bien qu’essentielle pour un code long terme est bien souvent oubliée ou ignorée par manque de temps. C’est une pratique à part entière qui mériterait bien son article dédié.

Avec cette succession d’étapes qui se répètent aspect partiel après aspect partiel, les tests permettent de se concentrer uniquement sur un aspect après l’autre, les tests ne sont finalement qu’un moyen d’arriver à la concentration unitaire. L’avantage des tests qui sont dans le cadre du TDD automatisé et non manuel (on a écrit du code dans ce but), est que nous allons pouvoir exécuter ces tests tout au long de la vie du logiciel, ce qui en fait un effet de bord incroyablement précieux et c’est une des raisons qui fait que certaines personnes pensent le TDD comme étant en premier lieu une méthode de tests plus qu’une méthode de développement.

Juste nécessaire

Un autre avantage que procure les tests et notamment de les écrire avant le code de production et dans l’écriture de la juste nécessaire quantité de code source de production.

En effet, lorsque l’on écrit un test afin de démontrer que ce cas-ci n’est pas résolu, on s’assure ainsi qu’il y a bien nécessité d’écrire du code source. Si nous reprenons notre exemple sur le test qui confirmerait la capacité du panier, s’il est vide, à retourner un montant total à 0, celui-ci pourrait très bien être déjà résolu dans le cas où nous aurions déjà traité le cas standard à savoir un panier non vide.

Pourquoi ? Parce que la somme d’une liste de lignes de produits vide retourne en fonction de l’implémentation peut être déjà 0. Sans tests nous aurions étaient tentés par le fait d’injecter une vérification sur le fait que le panier soit vide avec une structure « if » et donc nous aurions écrit du code source supplémentaire et inutile.

Ce point simplifie par la suite la maintenance et la conception de notre application, ce qui la rend plus robuste sur le long terme et répond une nouvelle fois au postulat « plus c’est petit, plus c’est simple« .

Un autre cas où le TDD amène la juste quantité de code source de production est le lancement très régulier des tests. Lorsque nous sommes dans l’étape où un unique test échoue (red), le premier objectif est de faire passer les tests (green). Pour cela, nous allons aller au plus simple, même si nous devons coder un retour en dur, ici une nouvelle fois, nous souhaitons se concentrer sur un unique aspect de notre fonctionnalité qui est répondre a un premier cas d’usage en « faisant passer les tests au vert« .

À ce moment précis nous savons que nous ne traitons qu’un cas parmi d’autres vient alors le temps de généraliser un peu plus en écrivant un second cas de test différent du premier qui va donc prouver que nous avons besoin de généraliser le code source de l’application. Lors de la réalisation du code source de production, c’est pareil si les tests passent alors je dois arrêter l’écriture du code source de production et écrire un nouveau cas de test qui prouve que je dois reprendre l’écriture de ce code source de production.

Ces étapes sont sur des temporalités tellement courtes que ce n’est pas du gâchis, nous généralisons donc seulement quand cela est nécessaire guidé par les tests que nous avons écris.

L’on voit ici de l’importance de se laisser guider par les tests et le comportement souhaité. Si nous sentons que nous avons encore besoin de généraliser un peu plus notre code source de production, alors il nous faut le démontrer par un cas de test supplémentaire.

Les trois lois du TDD

Les trois lois du Test Driven Development ont émergés afin d’entériner le principe d’un seul test en échec et d’un minimum de code source de production pour le faire passer. Ces trois lois sont les suivantes (source wikipédia Test Driven Development) :

1. « Vous ne pouvez pas écrire de code de production tant que vous n’avez pas écrit un test unitaire qui échoue. »
2. « Vous ne pouvez pas écrire plus d’un test unitaire que nécessaire pour échouer, et ne pas compiler revient à échouer. »
3. « Vous ne pouvez pas écrire plus de code de production que nécessaire pour que le test unitaire actuellement en échec réussisse. »

Ces trois lois font souvent débat dans les différentes approches, car elle nécessite une grande rigueur, voir parfois pour certaines approches, faire des étapes intermédiaires qui peuvent sembler inutile ou robotique. Par exemple, si je souhaite vérifier que pour mon panier contenant une ligne de produit dont le prix unitaire est 10 euros et la quantité 1 alors le montant total de mon panier doit être de 10 euros, le premier code source de production écrit dans la méthode montant_total sera un simple retour de la valeur 10 euros.

Dans ce contexte, le développeur sait très bien que ce n’est pas le code source de production final, il n’y a pas de doutes que ce code n’est pas assez généralisé. Mais l’application des trois lois permet aux développeurs d’écrire un second test qui permettra de justifier la généralisation et par conséquent qui rendra le code source de production plus robuste car cette généralisation sera testée.

Si nous reprenons notre exemple, le second test sera sur un panier composé d’une ligne de produit avec un prix unitaire de 5 euros et une quantité de 1, alors le seul moyen de faire passer les 2 tests sera de généraliser le code source de production.

Un point à garder en tête lors de l’application forte de ces 3 lois est : le code de vos tests se spécialisent de plus en plus pour gérer des cas des plus probables au moins probables alors que le code de production se généralise à chaque tests successif. Cela implique donc de ne pas traiter chacun des nouveau cas avec des structures de type « if » par exemple.

Ce dernier point est intéressant car il n’est pas possible de tester tous les cas (même en utilisant des générateurs de valeurs aléatoires). Dans notre exemple, un produit peut prendre une infinité de valeur par conséquent nous ne serons jamais en mesure d’écrire tout les cas de tests nécessaires, il faut donc généraliser le code de production.

La pyramide de tests

La pyramide de tests est un artefact bien connu dans la gestion de votre stratégie de tests, elle préconise de nombreux tests unitaires (car rapide et à faible coût) puis un niveau intermédiaire de tests d’intégrations (moyennement rapide et moyennement coûteux) puis un niveau faible de tests de bout en bout (peu rapide et assez coûteux) et enfin quelques tests manuels.

Cette pyramide fût longtemps la bible en terme de stratégie de tests. Commençons par une petite description très succincte des types de tests évoqués ci-dessus.

Les tests manuels sont des tests très haut niveaux, on utilise un système similaire à la production en maximisant cette ressemblance afin de voir comment le système réagit suite à l’ajout d’une fonctionnalité. L’environnement utilisé pour cela peut avoir différents noms préproduction, qualification… L’objectif ici est de valider que la nouvelle fonctionnalité peut être déployée et qu’elle s’intègre bien dans le logiciel.

Les tests de bout en bout eux sont des tests similaires aux tests manuels à la différence prêt qu’ils s’exécutent dans un environnement dédié et qu’ils sont automatisés et par conséquent beaucoup moins soumis à l’interprétation humaine sur des aspects visuels ou d’ergonomie. Ici les tests vont couvrir l’ensemble du spectre de l’application de l’interface graphique en passant par le serveur web puis le code source de l’application et enfin une base de donnée par exemple.

Les tests d’intégrations sont des tests visant à prouver que deux éléments d’un système communique bien ensemble, par exemple le code source de production fonctionne bien avec la base de données ou encore avec le serveur web.

Pour les tests unitaires, la notion fut soumise à interprétation, notamment sur le sens du mot unitaire. Certaines approches ont pu désigner par le terme unitaire toute unité de code, soit chaque fonction doit avoir son ou ses tests associés, ou encore chaque classe doit avoir son fichier de test associé et ce sans liaison avec un autre élément du système, on teste donc à un niveau très bas le logiciel.

Depuis un autre mouvement est apparu en plaçant au sein du mot unitaire, l’idée de concept ou de besoin, de fonctionnalité il en résulte alors que par exemple toute portion de code accessible depuis l’extérieur du système doit être testée et que cette notion d’unitaire peut finalement être plus ou moins fine en fonction du contexte. Ce second mouvement amène alors la notion de tests d’acceptation entre les tests unitaires fins et les tests d’intégrations. Ces tests d’acceptation n’étant finalement que des tests unitaires plus gros que les tests unitaires fins.

Prenons un exemple, si je teste ma fonctionnalité montant total et que pour réaliser cette fonctionnalité, j’ai dans un premier temps (avant refactoring) codé au sein d’une unique méthode. Si je découpe cette méthode pour la composer de 3 méthodes distinctes, en fonction de la lecture initiale de la pyramide je devrais associé à chaque méthode un test pour respecter le fait d’avoir une base de tests unitaires couvrant le maximum de code source de production. Ou alors selon le second mouvement, je pourrais ne tester que la méthode globale de la fonctionnalité et rendre les 3 autres méthodes privées, en considérant l’unité au niveau de la fonctionnalité, au niveau de la méthode publique.

Avec cette seconde approche, nous avons toujours la même couverture de test car les 3 méthodes privées sont indirectement testées par le test de la méthode publique, l’avantage ici est que les tests se superposent beaucoup moins et sont donc plus robuste. Le changement sera donc plus facilement intégrable à l’avenir et évitera pour une modification d’avoir de nombreux tests à revoir.

Double boucle du TDD

Comme nous l’avons vu, avec une approche par l’extérieur (outside in), on découpe le problème en considérant que l’on sera capable d’augmenter la capacité du logiciel sur les éléments plus bas dans la hiérarchie car plus simple (ils ont moins de responsabilités). La double boucle du TDD se décompose comme ceci lors d’une approche outside in.

Premièrement je vais tester mon logiciel par le moyen d’accès à ma fonctionnalité, une api REST par exemple. Mon premier test sera donc de tester la capacité de mon logiciel à me fournir un point d’accès avec le comportement global souhaité par exemple le calcul du montant total de mon panier. Ce test est à un niveau test d’intégration car je vérifie que mon contrôleur par exemple m’apporte le comportement attendu en passant par le code métier et en se connectant à la base de données. Notons ici que je suis sur une approche assez classique CRUD utilisé au sein d’un framework MVC par exemple, nous n’allons pas ici pour le moment entrer dans la notion d’architecture hexagonale ou d’autres types d’architecture permettant le découplage entre code métier et code d’infrastructure, l’architecture hexagonale mériterait aussi son propre article.

J’ai donc un premier test très haut niveau, c’est ma première boucle, ensuite je vais descendre à un niveau plus bas lorsque je vas vouloir amener du comportement sur ce point d’accès, je vais donc pour cela écrire un nouveau test qui sera un test unitaire pour le comportement partiel de ma fonctionnalité et c’est ainsi que j’entre dans ma seconde boucle du TDD car le premier test ne passant pas je le commente le temps de faire passer le test de la seconde boucle. Une fois cela fait je dé-commente mon premier test et je passe à l’aspect partiel suivant et ainsi de suite.

Le principe peut se répéter plusieurs fois en fonction de votre fonctionnalité et de la façon de découper votre problème. L’idée principale étant de partir de l’extérieur, de coder comme ci vous aviez les aspects partiels nécessaires déjà réalisés. Puis de réaliser unitairement chacun de ces éléments partiels. Enfin vérifier que votre test de haut niveaux passe bien.

Les variantes

Il existe de nombreuses variantes dans la pratique du TDD, différents principes ont émergés au cours des années. L’un des premier principes étaient le Test First Design, dont la principale pratique était d’écrire les tests avant le code source de production. Puis est arrivé le fait qu’il n’y ai qu’un seul test qui échoue et ainsi de suite.

Pour citer quelques variantes des plus connues on retrouve le TDD inside out, le TDD outside in qui sont les deux principales approches connues.

La première va partir de l’intérieur du système vers l’extérieur. On commence donc par les éléments les plus bas dans notre hiérarchie d’abstractions et cette approche va demander des tests individuels de chaque méthode créée pour respecter les principes du TDD, il y aura donc, lorsque l’on remontera vers les éléments plus haut dans la hiérarchie, des superpositions de tests. Cette redondance peut être lourde à gérer au fil du temps et amener une certaine fragilité.

La seconde approche va partir de l’extérieur du système vers l’intérieur. On commence ici par le comportement souhaité, les cas d’utilisation des éléments publiques de notre système, par exemple une api. On va ensuite écrire le code juste nécessaire pour répondre au comportement souhaité et en ajoutant comportement après comportement nous allons étendre les capacités de notre application en descendant dans les éléments de notre hiérarchie. Tout remaniement de code ayant pour but de changer la forme sans modifier le comportement, nous n’aurons alors pas besoin d’écrire de tests supplémentaires et la superposition de tests se trouvera bien moindre que dans la première approche.

Une nouvelle approche est en train de se répandre, basé sur l’outside in TDD elle se nomme outside in diamond, …

Outside In Diamond

L’approche outside in diamond utilise de nombreuses notions de l’industrie, elle se pratique notamment avec une gestion forte de la différenciation du code métier et du code d’infrastructure, des notions que vous retrouverez par exemple dans l’architecture hexagonale.

Dans cette approche, il va être conseiller d’écrire le maximum de tests d’acceptations (tests unitaires assez gros à un niveau fonctionnalité par exemple), plus que de tests unitaires fins d’où la forme en diamant.

Ici la double boucle du TDD appliqué à un système découplé entre le code métier et le code d’infrastructure va permettre d’avoir des tests rapides au niveau tests unitaires fins ET tests d’acceptations, car nous n’allons pas démarrer de base de données ou de serveur web pour ceux-ci, mais l’architecture va permettre de simuler l’appel comme s’il provenait d’un serveur web.

Par contre cette double boucle commencera alors par un test d’acceptation plutôt qu’un test d’intégration, mais n’entraînera pas forcément la superposition avec des tests unitaires fins si cela n’est pas nécessaire nous aurons donc bien plus de tests d’acception que de tests unitaires ou de tests d’intégrations. Cette double boucle ne sera donc pas réalisée systématiquement mais seulement dans les cas complexe à faire émerger.

J’affectionne particulièrement cette approche, car je l’utilisais déjà sur des systèmes de framework CRUD – MVC avec les tests d’intégrations à la place des tests d’acceptation, ici avec l’approche architecture découplée on accélère les tests ce qui est un point positifs indéniables.

Les avantages de cette approche sont pour moi important, on ne code que du code nécessaire et on ne perd pas en couverture de tests, on est plus rapide sur l’exécution des tests et on est donc plus efficace.

Pour aller plus loin, cette pratique est notamment diffusé par Thomas Pierrain :

• https://tpierrain.blogspot.com/2021/03/outside-in-diamond-tdd-1-style-made.html
• https://www.youtube.com/watch?v=djdMp9i04Sc

Pour finir

En quoi le fait d’écrire le test avant le code source de production est-il important ?

Premièrement lorsque l’on écrit les tests avant on ne les oublie pas, la pire situation que vous pouvez rencontrer en fin de session de développement est un test qui ne passe pas sans code source en face, dans l’approche classique de l’écriture des tests à posteriori, il n’est pas rare qu’une urgence vous sorte de votre session de développement et que vous vous retrouviez avec du code source de production sans tests en face, ce qui est bien plus dangereux à long terme. De même en écrivant en premier lieu le test votre code source de production sera testable ce qui n’est pas toujours simple dans l’approche à posteriori.

Second point, le fait d’écrire un test en premier en partant du comportement souhaité va vous orientez dans le nommage des éléments nécessaires, ce nommage traduira plus simplement votre intention de plus, l’architecture de votre solution sera aussi émergente et en juste à temps. Le changement ne deviendra plus un problème et vous aurez moins besoins de faire de l’architecture lourde en amont mais une architecture plus légère au fur et à mesure de la découverte des besoins.

Petit bonus, vos tests sont importants autant que le code source de production, ils vous seront alors utiles sur bien des aspects. Les tests sont votre documentation d’utilisation de votre application. Chacun des tests représentant un cas d’usages possibles de votre application, pensez donc à en prendre soin afin de maximiser leurs utilisabilités.

Comme nous avons pu le voir je suis convaincu par cette pratique depuis de nombreuses années, je vous ai résumé quelques aspects qui m’ont convaincus au cours de ces années, bien évidemment il y a de nombreuses autres approches, chacune avec leurs avantages et leurs inconvénients, pas de silver bullet une nouvelle fois.

Cette pratique nécessite une certaine rigueur et une changement de paradigme notamment sur l’écriture du test en premier qui peut se révéler douloureux dans les premiers mois mais une fois que l’on a en main cette pratique on a du mal à la lâcher.

A bientôt pour d’autres pratiques craft.

Image par PublicDomainPictures de Pixabay

Il n’est pas rare dans le monde du développement logiciel que les fameuses transformations agiles malgré une connaissance pointue des méthodes agiles théoriques deviennent des échecs et cela pour de nombreuses raisons. Quoi qu’il en soit, je vais au travers de cet article vous faire un feedback sur les éléments qui peuvent éviter cet échec pour maximiser les chances de transformations et donc que représente pour moi la conduite du changement agile.

Agilité et changement

Comme évoqué dans l’article précédent, les méthodes agiles sont souvent le point de départ des transformations agiles, c’est déjà une première source de difficultés. Effectivement dans transformation agile, il y a agile et donc méthodes agiles bien sûr mais le premier terme reste bien transformation. Il est donc plus efficace de démarrer celle-ci par la capacité et la volonté de changer. Cela passe par des étapes de constats partagés et la communication sur le changement souhaité en indiquant principalement le contexte autour de ces choix, ce qui vous a amené à entrer dans une phase de transformation.

Il faut donc faire preuve d’une grande transparence, démarrer un changement dans l’obscurité ou le mensonge n’a guère de chances d’amener à un résultat positif. Un exercice intéressant est de répondre à quelques questions simples :

1. D’où part-on (contexte et constats) ?
2. Quels sont les éléments qui nous ont convaincus qu’une transformation est nécessaire (déclencheur) ?
3. Quel est l’objectif attendu (donner la vision même si celle-ci est incertaine) ?

Ces trois questions ont des objectifs différents. La première question a pour objectif de partager sur l’état actuel de la situation. Cela a pour effet de limiter la résistance au changement qui est tout à fait naturelle. En expliquant le contexte et les constats qui ont permis de prendre une décision, les personnes se sentent plus concernées par le changement et moins soumises au changement. La deuxième question permet de révéler les déclencheurs (opportunités, mise en place d’indicateurs, concurrences, évolutions du marchés, nouveau projet…) qui sont à l’origine du démarrage de la transformation. Enfin, la troisième question permet aux personnes de comprendre les objectifs et l’intérêt attendus d’un tel changement (financier souvent mais pas que ;), bonheur au travail, humain, efficacité, écologie…), ce point est forcément hypothétique c’est une vision d’entreprise qui sera ou non vérifiée à l’avenir. Si cette vision fait référence aux valeurs des personnes de l’équipe, elle permettra de les faire passer de personnes subissant le changement à personnes moteurs pour amener le changement. Ce qui aura un impact fort sur la réussite du changement agile. L’alignement vers un objectif commun des parties prenantes du changement est un prérequis au bon déroulement de la transformation et lorsque des situations compliquées apparaîtront il sera alors plus aisé de passer à la recherche de solutions plutôt que de coupables.

Une fois le cadre du changement posé et partagé, nous pouvons parlé du contenu et surtout de la mise en place de la transformation agile.

La conduite du changement

Comme évoqué au paragraphe précédent, il existe parfois des résistances au changement. Cette situation peut trouver des explications dans le fait de passer d’un état connu à un état inconnu ou dont les conséquences ne sont pas encore mesurables. Dans un état connu même si celui-ci ne nous convient pas nous avons tendances à se sentir en zone de confort, les mêmes actes ayant les mêmes conséquences. Dans un état inconnu qui pourrait être meilleur pour nous, nous ne connaissons pas encore les conséquences des mêmes actes ou d’actes nouveaux, il faut donc sortir de sa zone de confort pour l’explorer.

Pour éviter de déstabiliser une équipe, un projet et un quotidien en place, il existe des solutions pour amener le changement au sein du quotidien. Nous pouvons par des petits ajustements amener des notions et des pratiques plutôt qu’un chamboulement complet du jour au lendemain. Cette conduite du changement permet aux différents acteurs de pouvoir progressivement monter en compétences sur les nouvelles méthodes de travail sans subir un changement trop brusque qui risquerait d’être perçu comme une douleur.

Pour se faire les principes d’amélioration continue sont une aubaine. L’accompagnement par une personne connaissant les pratiques agiles et leurs apports peut être intéressant afin de pouvoir répondre aux différents axes d’améliorations exprimés. En se basant sur les axes d’améliorations prioritaires, l’équipe décide de mettre en place une nouvelle pratique agile, elle en mesure alors les bénéfices ou non et décide ensuite de l’entériner ou non en fonction des retours.

Cette conduite du changement agile permet une meilleure acceptation du changement et se place clairement dans un principe évolutif à long terme. Le prérequis est de trouver l’inspiration des pratiques agiles adaptées au contexte de l’équipe.

Les méthodes agiles et la culture agile

La mise en place d’une transformation, nécessite une inspiration. Comme nous avons pu le voir précédemment cette inspiration se trouve souvent dans les méthodes agiles prêtes à l’emploi et à appliquer « by the book » or cette application peut avoir plusieurs conséquences néfastes sur la transformation. Par exemple une équipe ne pratiquant pas du tout l’agilité au quotidien et qui devrait utiliser l’entièreté de la méthode Scrum du jour au lendemain pourrait se retrouver dans les écueils suivants :

• Perte de repères sur les responsabilités et de la place de chacun
• Sentiment d’insécurité
• Sentiment d’inefficacité
• Perte de motivation
• Échec de la transformation agile
• …

La conséquence serait un retour arrière rapide aux anciennes méthodes ou pire la méthode Scrum serait imposée et ferait naître un sentiment de rejet et des conclusions hâtives sur l’agilité.

C’est là que la conduite du changement agile et la culture agile ont toutes leur importance. A l’application d’une méthode, il est préférable de mettre en place des pratiques agiles correspondantes aux situations et contextes rencontrés.

Par exemple si vous avez régulièrement des incompréhensions avec le métier sur les fonctionnalités à développer, il peut être intéressant de mettre en place un atelier de co conception de la solution pour répondre aux besoins des utilisateurs finaux en présence des développeurs concernés et sans intermédiaire entre le métier et les développeurs.

Si le métier souhaite régulièrement apporter des changements ou vous indique lorsqu’une fonctionnalité est développée qu’elle n’est plus utile et qu’il ne sert à rien de la mettre en production, il est tout à fait possible de mettre en place un point hebdomadaire pour échanger sur les fonctionnalités et leurs priorités et ainsi retirer les fonctionnalités sans valeur.

Enfin si le métier vous indique régulièrement que la fonctionnalité mise en production ne correspond pas du tout aux besoins, une démonstration avant la mise en production est envisageable.

Sur ces 3 exemples, vous avez un premier pas vers une collaboration plus efficace tout en ne bouleversant pas un équilibre déjà fragile. Dans ces 3 cas, l’agilité arrive sans être nommée mais on retrouve des pratiques agiles (avec des inspirations de SprintReview, d’affinage de backlog…).

Toute nouvelle pratique nécessite appropriation, et donc du temps et de l’entraînement. Nous comprenons alors que le changement du tout au tout est un effort souvent trop lourd et mène à l’abandon. L’amélioration continue et la communication autour des problèmes rencontrés au quotidien afin de trouver les pratiques adaptées est donc une voie beaucoup plus efficace pour un changement agile.

Cet article relate des premiers pas dans l’agilité, une fois le mouvement enclenché il ne tient qu’à vous de le perpétuer tout au long de la vie de votre équipe.

Le changement agile est infini.

Des questions sur l’agilité, scrum et leurs mises en application dans votre contexte, n’hésitez pas à me contacter.

Image by Antonio López from Pixabay

Une même pratique sous des formes différentes

La pratique sous-jacente à toutes les activités énumérées ci-dessus est la même. Dans tous les cas les personnes souhaitent avoir un partage d’expériences avec l’intervenant. La différence se fait donc au niveau de la forme de l’intervention plus que son contenu. Si nous reprenons l’exemple des termes citées plus haut un coach agile sera en retrait de l’opérationnel et interviendra plus via des conseils auprès des personnes clés de l’organisation. Là où un scrum master ou un facilitateur, interviendra réellement dans l’opérationnel et durant les réunions et autres points d’organisation, il prendra aussi en charge des activités chronophage et qui ne nécessite pas une interruption des équipes opérationnelles. Pour ces deux premiers cas, l’activité est centrée sur une organisation, une entreprise, un contexte donné. Pour le conférencier ou encore le formateur, c’est un peu différent car il intervient auprès de plusieurs organisations et donc plusieurs contextes en même temps. Le partage de l’expérience sera donc plus généralistes comme les cas d’exemple vécu.

Les quiproquos et la souplesse

La méprise entre les termes est légion, l’offre fait état d’un besoin de scrum master mais en fait le client a plus besoin d’un coach agile car il ne souhaite pas créer de dépendances envers l’intervenant. Encore une fois le nom du poste pour un besoin dépend de l’entreprise et il ne faut pas s’y arrêter et savoir rester souple, l’important étant ce qu’on fait et non l’intitulé de la fiche de poste. Je fais depuis quelques temps de plus en plus de café visio (discussion informelle autour d’un café en visio-conférence si ça vous intéresse n’hésitez pas ), lors de ces échanges très intéressants j’ai pu rencontrer différentes personnes du domaine et la tendance à ne plus tenir compte des termes grandies. L’important n’est pas le nom d’un poste mais ce qu’on y fait et comment on le fait. Le reste n’est qu’un mot sur un cv ou une fiche de poste ou encore un profil Linkedin, une notion abstraite qui essaie tant bien que mal de représenter une complexité importante.

Difficile de croire qu’un terme permet de représenter les activités quotidiennes d’une personne, un terme pour 35h par semaine pour 220 jours par an, l’exercice est très difficile notamment dans les métiers où l’adaptation au contexte est permanente et où chaque élément est susceptible de changer à intervalle régulier.

Des questions sur l’agilité, scrum et leurs mises en application dans votre contexte, n’hésitez pas à me contacter.

Image par AJS1 de Pixabay

Dans une organisation qui s’oriente vers l’agilité, la culture reste, les méthodes et process changent.

La culture est composée des valeurs et de la vision que porte une entreprise. C’est un état d’esprit, des convictions humaines, quelque chose de peu palpable et qui ne se transmets que par la proximité et l’exemple concret sur le terrain. Impossible de transmettre une culture de qualité dans le développement logiciel si on interdit aux développeurs de mettre en place des pratiques qui vont avec (par exemple les tests automatiques ou encore le Test Driven Development).

Les méthodes et process sont là pour apporter une organisation pour atteindre un objectif, une vision en fonction d’un contexte donné hors ce dernier ne cesse d’évoluer (textes de lois, concurrence, évènements extérieurs…), il n’est pas sous notre contrôle et par conséquent il est source d’inquiétudes.

S’adapter au contexte, au changement est primordial parce qu’il n’existe pas de solution miracle répondant à tous les contextes, si c’était le cas elle aurait un succès phénoménal, parce que les cadres de travail font intervenir l’humain et chaque personne perçoit les choses différemment. Parce que les méthodes et process qui ont fait les succès d’hier feront peut être l’échec d’aujourd’hui. Ce monde en perpétuel mouvement implique donc d’être en capacité de changer lorsque cela est nécessaire.

Pour changer il faut passer par l’étape de la remise en question de l’existant, on ne peut faire changer une organisation qui lutte de toutes ses forces pour rester dans un état identique. Il faut donc travailler à partir de ce point à constater ce qui fonctionne bien et ce qui fonctionne moins bien aujourd’hui. A partir de ces précieux retours, il faut en saisir l’essence, la cause racine, le point d’action qui aura avec un minimum d’effort le plus de résultats.

Lorsque cette activité de remise en question de l’existant est réalisée suffisamment souvent une amélioration par petite adaptation est envisageable, dans le cas contraire des gros changements peuvent être nécessaires mais les impacts et effets de bords seront plus forts voire dangereux.

« Il n’y a qu’une seule chose dans la vie qui ne change jamais, c’est le changement ». Cette citation de Confucius représente bien l’acceptation du changement nécessaire à l’évolution et l’amélioration continue. Cette notion est plus qu’importante dans la culture agile, elle est même pour moi un des piliers. C’est ce changement de contexte perpétuel qui nous pousse à aller toujours plus loin, à améliorer les choses et à définir les bonnes pratiques à adopter dans ce contexte. Que ce soit d’un point de vue technique ou organisationnel, la base de toutes améliorations reste l’acceptation que le contexte à changer par bien des aspects possibles.

Lors de coaching agiles ou lorsque l’on arrive comme faciliatateur / scrum master au sein d’une équipe, une fois la prise de contexte réalisée, vient le temps de la proposition d’outils et de méthodes permettant de traiter les points de douleurs, d’adapter l’organisation et les process en place pour plus d’efficacité.

Des questions sur l’agilité, scrum et leurs mises en application dans votre contexte, n’hésitez pas à me contacter.

Image par Gerd Altmann de Pixabay

L’agilité était tellement peu formalisée sur les premières années qu’il a fallu décrire la façon de la mettre en place à travers des méthodes agiles dont les plus célèbres : Scrum, Extreme programming, SAFe pour ne citer que celles-ci. Et là c’est produit un phénomène tout à fait classique, les méthodes qui sont des guides très complets on pris le dessus sur les concepts d’agilité eux mêmes. On connaît tous le « Nous on fait du Scrum », ou « On bosse avec la méthode agile (aka Scrum) », … Pourquoi ? Parce que les méthodes ci-dessus laissent moins de liberté d’interprétation et donc réduit le champs des possibles, elles sont donc bien plus aisées à appliquer et à faire appliquer. Cela donne un cadre, des directives à suivre. Ce qui est un bon point de départ mais peut très vite s’avérer être inadapté à votre contexte.

Lors de nombreuses présentations des concepts d’agilité que je peux donner ou auxquelles je peux assister. Une question revient régulièrement : « Au quotidien que mettez vous en place ? ». Cette vision pratique d’éléments théoriques est tout à fait logique dans un processus de changement et donc tout naturellement si quelqu’un a écrit une méthode à appliquer point par point on se tourne dans un premier temps au moins vers celle-ci. Ce que font très bien les dites méthodes agiles, et cette application d’un guide méthodologique agile peut convenir à certaines équipes. Suivre ces méthodes lorsque l’on ne sait pas par où commencer est un exercice tout à fait intéressant, il permet de voir les avantages et inconvénients de certaines pratiques agiles. Mais parfois l’application étant trop contraignante, nous préférons alors arrêter tous le processus de changement plutôt que d’adapter la méthode à son contexte par peur de diverger de la méthode originelle.

Et lorsque ces présentations exprime le quotidien d’équipes agiles certaines réponses sont de l’ordre : « Ah oui mais ça nous on ne peut pas le faire ! ». Toutes les pratiques données sont prises comme les éléments nécessaires d’une méthode à appliquer à la lettre et dans leur totalité le changement paraît impossible. Appliquer les principes agiles de manière identique ou pas n’est pas la question, la question est plutôt comment pouvons-nous nous inspirer de ce qui se fait ailleurs afin de créer notre propre méthode adaptée à notre contexte et qui évoluera au fur et à mesure ? L’idée préconçue qu’on est ou qu’on est pas agile de manière binaire n’est pas réaliste. Aucune équipe passe, après une semaine de formations, d’un mode basé sur le contrôle total à une agilité bienveillante. L’agilité est un chemin qu’il faut tracer en équipe en ayant bien assimilé le sens des principes pour pouvoir après les appliquer au fur et à mesure des situations rencontrées.

Et c’est bien là où réside toute la difficulté, adapter les pratiques agiles aux contextes. Car comme vous l’aurez compris il n’existe alors plus une méthode agile mais autant de méthodes agiles que d’équipes qui la pratiquent. Lors de coaching agiles ou lorsque l’on arrive comme faciliatateur / scrum master au sein d’une équipe, la première étape est donc de comprendre le contexte afin de pouvoir proposer des bonnes pratiques aux bons moments en fonction des difficultés et des situations de chaque équipe.

Des questions sur l’agilité, scrum et leurs mises en application dans votre contexte, n’hésitez pas à me contacter.

Image par Gerd Altmann de Pixabay

PHP 7.3.19-1 .....

Mise à jour de PHP

Pour mettre à jour votre version de PHP, il faut suivre les premières étapes suivantes :

Téléchargement et ajout de la clé gpg pour le dépôt PPA de PHP :

sudo apt -y install lsb-release apt-transport-https ca-certificates 
sudo wget -O /etc/apt/trusted.gpg.d/php.gpg https://packages.sury.org/php/apt.gpg
echo "deb https://packages.sury.org/php/ $(lsb_release -sc) main" | sudo tee /etc/apt/sources.list.d/php.list

Ensuite installons PHP 7.4 depuis ce ppa fraîchement configuré :

sudo apt update
sudo apt -y install php7.4

A ce moment là si vous faites php -v vous devriez avoir un retour comme celui-ci :

PHP 7.4.9 ...

On peut donc en conclure que PHP a bien été mis à jour.

Cependant si vous mettez un fichier PHP avec un phpinfo(); à l’intérieur est que vous l’appelez à travers votre apache, la réponse sera que la version utilisé de PHP est la 7.3.

Deux versions de PHP en parallèle

Vous avez à ce moment là 2 versions de PHP installer en parallèle, la 7.3 et la 7.4, si vous n’avez plus besoin de la version 7.3 vous vous dites que vous pouvez la désinstaller sans souci avec sudo apt purge php7.3 suivi ou non par un sudo apt autoremove pour faire le ménage. Oui et non si vous faites cela à l’instant vous allez vous retrouver avec vos fichiers php qui ne seront plus interprété par apache (si ce n’est pas un serveur de prod vous pouvez faire le test).

Pourquoi mes fichiers PHP ne sont plus interprétés par apache

La réponse est logique mais pas évidente, comme je vous le mentionnais en début d’article, l’installation du méta paquet php installe aussi apache2 et le module libapache2-mod-php. Tout ceci fonctionne bien ensemble, php 7.3 compatible avec libapache2-mod-php développé pour la version spécifique de php 7.3, donc lorsque l’on purge php7.3 il désinstalle le module apache associé et vos fichiers php ne sont plus interprétés par apache2.

Ok mais j’ai installé php7.4, ne m’a t-il pas installé libapache2-mod-php pour la version php 7.4 ? Vous avez raison le méta paquet php7.4 installe bien libapache2-mod-php pour la version php 7.4 mais ce derniers n’est pas automatiquement activé car il existait à ce moment là encore le module libapache2-mod-php pour la version php 7.3 et ces 2 modules sont incompatibles ensemble c’est pourquoi vous devez lancer les 2 commandes suivantes :

sudo a2dismod php7.3
sudo a2enmod php7.4

La première commande va désactiver le module libapache2-mod-php pour la version php 7.3 s’il est encore présent et la seconde va activer le module libapache2-mod-php pour la version php 7.4 enfin après systemctl restart apache2, vous pouvez vérifier votre fichier php contenant le phpinfo(); qui devrait maintenant vous indiquez PHP 7.4

Vous avez retrouver l’interprétation de vos fichiers PHP, la mise à jour est terminée, sauf s’il vous manque des extensions php à installer avec par exemple pour l’extension common :

sudo apt install php7.4-common

Vous pouvez aussi si vous le souhaitez purger les extensions php7.3 comme ceci sudo apt purge php7.3-common pour l’extension common.

Sources : https://geekmag.fr/blog/2020/01/25/installer-php-7-4-sur-debian-10-ou-debian-9/

Image par simplu27 de Pixabay

Pré-requis

• Une machine locale ou une vm sous ubuntu 20.04 ou équivalent (xubuntu 20.04 dans l’exemple)

Présentation de virtualenv

Virtualenv est un utilitaire permettant d’isoler vos projets python3 les uns des autres. Le but est d’activer un environnement virtuel différent pour chacun de vos projets afin d’y installer vos dépendances nécessaires (par exemple Django si vous faites un projet Django). Les dépendances sont comme vous le savez peut être installé par pip, le gestionnaire de dépendances Pyhton.

Résumé des étapes d’installation

Comme évoqué dans l’article sur l’environnement pour un projet Django, les étapes d’installation sont les suivantes pour une machine sous Ubuntu 20.04 :

sudo apt install python3-pip
pip3 install virtualenv

A partir de ce moment là vous devriez avoir accès à la commande virtualenv, malheureusement dans certains cas cela ne fonctionne pas est vous obtenez le message d’erreur suivant :

$ virtualenv venv3
Command 'virtualenv' not found, but can be installed with:
sudo apt install python3-virtualenv

A ce moment là il ne faut pas faire sudo apt install python3-virtualenv mais ajouter le chemin /home/USER/.local/bin dans votre variable d’environnement PATH dans votre fichier ~/.bashrc par exemple en fin de ce fichier insérer la ligne suivante en remplaçant USER par votre utilisateur Unix :

PATH="$PATH:/home/USER/.local/bin"

A partir de ce point il vous faut prendre en compte la modification réalisée ci-dessus. Pour cela il faut sourcer le fichier ~/.bashrc, soit en fermant et ouvrant de nouveau tous vos terminaux, soit en lançant la commande suivante : source ~/.bashrc

Vous devriez maintenant avoir accès à la commande comme ceci pour créer un environnement nommé venv3 :

$ virtualenv venv3
created virtual environment CPython3.8.2.final.0-64 in 919ms
creator CPython3Posix(dest=****/venv3, clear=False, global=False)
seeder FromAppData(download=False, pip=bundle, setuptools=bundle, wheel=bundle, via=copy, app_data_dir=***.local/share/virtualenv)
added seed packages: pip==20.1.1, setuptools==49.2.0, wheel==0.34.2
activators BashActivator,CShellActivator,FishActivator,PowerShellActivator,PythonActivator,XonshActivator

Si tout c’est bien passé vous devriez avoir un dossier venv3 créé dans votre dossier courant. Pour activer l’environnement il ne vous reste plus qu’à faire source venv3/bin/activate et devant votre prompt habituel vous devriez voir apparaître (venv3).

Dans le cas où vous avez fait sudo apt install python3-virtualenv, pas de panique vous pouvez avoir le message d’erreur suivant :

$ virtualenv venv3
ModuleNotFoundError: No module named 'virtualenv.seed.embed.via_app_data'

Dans ce cas faites sudo apt remove python3-virtualenv
Ensuite ajouter le chemin /home/USER/.local/bin dans votre variable d’environnement PATH dans votre fichier ~/.bashrc par exemple en fin de ce fichier insérer la ligne suivante en remplaçant USER par votre utilisateur Unix :

PATH="$PATH:/home/USER/.local/bin"

Prenons en compte le changement, soit en fermant et ouvrant de nouveau tous vos terminaux, soit en lançant la commande suivante : source ~/.bashrc

Vérifions que tout est de nouveau opérationnel en lançant la commande :

$ virtualenv venv3
created virtual environment CPython3.8.2.final.0-64 in 919ms
creator CPython3Posix(dest=****/venv3, clear=False, global=False)
seeder FromAppData(download=False, pip=bundle, setuptools=bundle, wheel=bundle, via=copy, app_data_dir=***.local/share/virtualenv)
added seed packages: pip==20.1.1, setuptools==49.2.0, wheel==0.34.2
activators BashActivator,CShellActivator,FishActivator,PowerShellActivator,PythonActivator,XonshActivator

De même, un dossier venv3 sera créé dans votre dossier courant. Pour activer l’environnement virtuel comme précédemment taper source venv3/bin/activate et il apparaîtra devant votre prompt habituel le contenu (venv3).

Voici pour un petit résumé des erreurs potentielles assez courante sur l’installation de virtualenv, pour information les indications donné dans cet article apparaîsse lorsque la commande pip3 install virtualenv se termine mais il n’est pas rare d’aller un peu vite et de ne pas faire attention aux indications donner par le retour de cette commande d’installation.

Pour la suite n’hésitez pas à tester le tutoriel sur un projet Django qui permet de voir quelques aspects de la mise en place de cette technologie.

Image par Falkenpost de Pixabay

Les symptômes

Ces derniers temps j’ai pas mal (pour pas dire beaucoup) travaillé sur mes machines virtuelles j’en ai créées, supprimées, dupliquées à partir de snapshot, … Et il arrive toujours un moment où on se mélange un peu les pinceaux entre les 5 vms Ubuntu et les 3 debian sans parler de la lubuntu et on se dit mais ça je suis sûr ça a marché il y a quelques semaines mais sur quelle vm et comment ? Le ça représente quelque chose d’assez simple, le but est d’accéder à une application django tournant en serveur de développement sur un système invité depuis le navigateur du système hôte. Trop facile vous dîtes, attendez la suite.

Par défaut sur un projet django, lorsque l’on lance la commande ./manage.py runserver, le serveur de développement se lance sur http://127.0.0.1:8000, ok classique pour un serveur de développement local, pas surpris. Ayant aisément fait une redirection de port dans virtualbox pour rediriger le port 2222 de la machine hôte vers le port 22 de la machine invitée, je pars la fleur au fusil faire une redirection tcp du port 8080 de la machine hôte vers le port 8000 de la machine invité, je prends mon plus beau navigateur et je tape dans ce dernier http://127.0.0.1:8080 et là ça ne marche pas (sinon j’écrirais pas cet article ).

La première solution mais pas la bonne à mon goût

Après avoir cherché vraiment longtemps, je me dis ce n’est pas grave on a une connexion ssh on peut donc tout faire passer par là avec un joli tunnel ssh (redirection de port à travers ssh et non plus virtualbox) comme ceci : ssh -L 8080:localhost:8000 user@localhost -p 2222, un peu d’explication -L pour redirection locale de port, 8080 le port de la machine hôte que j’ai choisi pour accéder à la machine distante (ici une machine invitée dans virtualbox). Localhost:8000, représente ici le localhost et le port de la machine sur laquelle la connexion ssh va s’opérer, ici cela représente donc bien le 127.0.0.1:8000 de base du serveur django. Enfin user@localhost -p 2222 représente la façon dont je me connecte sur la machine distante (ici la machine invitée sous virtualbox) car quand je veux me connecter en ssh sur la machine invitée je lance la commande suivante ssh -p 2222 user@localhost (fonctionnant par une redirection de port virtualbox). Ensuite je prends mon plus beau navigateur et je tape dans ce dernier http://127.0.0.1:8080 et là ça marche super on a dû « hacker » notre propre système sous notre maîtrise toute relative pour pouvoir accéder à une interface web. Enfin au passage ça rappelle de bon moyens de se faire un VPN pas chère ou toutes choses du genre…

La seconde solution, c’est la bonne

Bon le souci de la première solution c’est quelle laisse le doute sur le fait que la redirection de ports en virtualbox ne fonctionnerait que pour le port 22 forcément ce n’est pas possible, j’ai fait de nombreuses recherches sur internet qui m’indiquait le contraire. Ou alors serait-ce mon système hôte Ubuntu dans mon cas, pareil après quelques recherches cette hypothèse et écartée. Le firewall d’ubuntu à coup d’iptables et de ufw je m’aperçoit que non. Cela reste très gênant et enfin je décide d’orienter mes recherches vers django et là je tombe sur ce forum https://ubuntuforums.org/showthread.php?t=2260190 et là je comprends mieux, la redirection de port en tcp du port hôte 8080 vers le port 8000 de la machine invitée fonctionnait parfaitement bien depuis le début mais simplement django n’acceptez que les connexions locales. La solution est trouvée il faut lancer la commande suivante afin que le serveur accepte les connexions non locales ./manage.py runserver 0.0.0.0:8000 (bien évidemment il faut penser à reconfigurer la redirection de ports si vous l’aviez enlevé) et voilà tout fonctionne parfaitement. Le 0.0.0.0 indique dans ce cas toutes les adresses ips de la machine sur toutes ses interfaces réseaux, ce qui est bien plus ouvert que 127.0.0.1 qui lui n’autorisera la connexion que sur la boucle locale (=> localhost), des infos en détails ici : https://www.it-swarm.dev/fr/networking/quelle-est-la-difference-entre-127.0.0.1-et-0.0.0.0/958652984/

Mais alors pourquoi le pont ssh fonctionnait

Et bien simplement parce que lorsque que l’on met en place le pont à travers SSH, la connexion entrante est considérée comme une connexion locale pour django il n’y a pas de traces de la machine hôte pour django seulement pour ssh, une traduction en quelques sortes (souvenez vous le localhost de la machine distante ), tout s’explique et c’est bien mieux ainsi. Conclusion pour développer en python – django depuis une vm virtualbox et avoir le navigateur sur la machine hôte, il faut prendre le réflexe de lancer le serveur avec l’ip 0.0.0.0 plutôt que de laisser celle par défaut. Bon on peut faire autrement mais je vous en parlerais dans un prochain article où je vous donnerais un petit bonus patience…

Image par xresch de Pixabay

Contexte

J’utilise au quotidien des outils et logiciels libres comme Ubuntu, debian pour les systèmes d’exploitation, Python (Django), Ruby (Ruby On Rails), PHP (WordPress) pour les langages de programmation / frameworks / Content Management System, MariaDB, PostgreSql, Mysql, Sqlite pour les bases de données, Apache2, Nginx pour les serveurs web et Vim, GtimeLog, Gitlab, Framagenda (NextCloud), Tmux, Firefox, Brave, Zsh (Oh My Zsh), KeepassXC, Androïd, Mattermost, Jitsi pour les outils divers et variés… Et celui dont je vais vous parler aujourd’hui Kanboard pour la gestion de projets de développement logiciel.

Pour redonner à la communauté libre un peu de ce qu’elle m’apporte quotidiennement je réalise ce blog avec des articles afin de promouvoir les logiciels libres notamment dans leur utilisation et leur complémentarité afin de réaliser des projets de développements logiciels comme par exemple en python, j’essaie alors de vulgariser l’accès à ces technologies qui demandent bien souvent de comprendre un peu plus en profondeur les concepts qu’il y a derrière plutôt que de faire du « clickodrome » sur un logiciel propriétaire.

Je donne aussi quelques conférences sur des retours d’expériences d’utilisation de logiciels libres et de méthodologies orientées vers le développement « craft » et comment ils peuvent se pratiquer au quotidien.

Bien mais pas suffisant

Malgré cette contribution déjà intéressante, cela ne me satisfaisait pas complétement, je me suis donc dit qu’il serait intéressant d’utiliser mes capacités de technicien pour les mettre à profit d’un logiciel libre et j’ai choisi Kanboard.

Les raisons de ce choix

Lorsque l’on se lance dans la contribution de logiciels libres, il y a tout un monde à découvrir, avec ses règles, ses concepts et son écosystème. Il est donc plus aisé de commencer avec des éléments connus, et non avec que des inconnus, comme en développement logiciel on va éviter de faire un projet avec que des éléments non maitrisés il faut placer un curseur entre innovation et sérénité.

L’avantage sur le projet Kanboard est que je l’utilise depuis 3 ans tous les jours pour des besoins professionnels et personnels. Je l’ai déjà installé (en tant qu’administrateur et non développeur du logiciel) plusieurs fois, je l’ai utilisé dans de nombreux cas différents, je connais donc bien le fonctionnel ainsi que les limites du produit. De plus, je savais que la personne en charge du projet était quelqu’un de disponible, que le projet était vivant (une nouvelle version du produit sort très régulièrement) et enfin que si nécessaire il était possible d’échanger en français même si dans les faits nous n’avons échangé que en anglais. Dernier élément qui m’a fait choisir ce projet, il est en PHP, technologie que je ne maîtrise pas à 100% mais que j’ai largement pratiqué dans une vie antérieure et même plus récemment.

L’objet de cette première contribution

Passons sur le fond de cette première contribution qui comme je vous le conseille se doit d’être humble envers le logiciel choisi. Comme tout processus commencer petit permet d’avancer là où commencer trop gros peut être décourageant. Appliquant ce conseil, je me suis dis que j’allais commencer par suivre la documentation des contributeurs (avant de chercher une fonctionnalité à réaliser il faut mettre en place un environnement de développement et de tests), le projet tournait d’après la documentation via Vagrant et son Vagrantfile. Et à ma grande surprise (en fait non) la documentation n’était pas à jour sur cette partie qui concerne assez peu de personnes (seulement les nouveaux contributeurs du projets). J’ai donc dû dans un premier temps réussir à démarrer le projet en local avec les éléments de la documentation qui n’était plus à jour (cela s’apparente ici un peu à déboguer, se renseigner et remplacer les éléments bloquants) en modifiant le Vagrantfile. Une fois le projet lancé en local sur mon ordinateur j’ai pu lancer les tests automatiques afin de vérifier que rien ne manquait, ce fût le cas, j’en ai profité pour faire un peu de ménage sur ce Vagrantfile notamment dans la partie script. Voici donc ma première contribution libre faisant intervenir mes compétences de technicien afin de mettre à jour l’outil de démarrage du projet pour les contributeurs.

Cette notion est particulièrement importante pour un logiciel libre car c’est l’équivalent d’un installeur de logiciel pour un utilisateur non technicien, s’il faut savoir compiler le noyau linux pour installer un logiciel, il y a de fortes chances que les utilisateurs non techniciens passent leur chemin pour la plus part. Ici c’est un peu pareil si pour un projet libre les outils et la documentation pour le démarrer en local ne sont pas clairs et efficaces (« automatisés ») il se peut que certains contributeurs passent leur chemin.

Et après ?

Une fois la modification réalisée, je l’ai proposé suivant le processus défini par l’auteur du projet (en le suivant au maximum avec beaucoup d’humilité encore une fois, on collabore on se s’impose pas) une journée plus tard mon code était mergé dans la branche master du projet Kanboard. SUPER !

Oui mais maintenant la documentation n’était plus du tout cohérente avec le Vagrantfile modifié même si celui-ci fonctionné alors qu’avant la contribution il était cassé, j’ai donc de suite enchaîné avec une seconde contribution pour mettre à jour le dépôt dédié de la documentation afin de rendre la documentation représentative de la réalité du logiciel. Et voilà en moins de 3 jours 2 contributions libres réalisées et mergées dans les projets.

Conclusion

Cette contribution fût salvatrice pour moi elle m’a permis de démystifier un univers parfois fantasmé que peut être le logiciel libre. De plus, avec ces 2 contributions rapides et efficaces (utiles aux nouveaux contributeurs le cas échéant) le sentiment de retour à la communauté est très agréable et donne envie de continuer, ce qui se profil bien car même pour une modification mineure d’un article sur Ubuntu (par exemple sur la partie tmux à travers ssh), il est devenu automatique pour moi de participer sans crainte que cela ne soit trop difficile ou long. D’autres contributions sur des logiciels libres viendront sûrement dans les prochains mois et je ne manquerai pas de vous les faire partager afin de vous distiller au passage quelques conseils suite à ces expériences enrichissantes.

Image par Shri ram de Pixabay

Les pré-requis

• Un poste de développement avec Ubuntu 20.04 installé
• Un projet Python3 Django opérationnel pour le tutoriel nous utiliserons le projet suivant : https://gitlab.com/julienanne/django-deploy-production-example

Installation des éléments nécessaires pour Python 3

Ubuntu 20.04 de son nom Focal Fossa est livré avec la version 3.8.2 de python sur la commande python3, cependant il nous faut installer pip, le gestionnaire de paquets Python ainsi que git à travers la commande suivante à exécuter en root :

apt install python3-pip git

Vérifions la bonne installation avec les 2 commandes suivantes :

python3 --version
# Python 3.8.2
pip3 --version
# pip 20.0.2 from /usr/lib/python3/dist-packages/pip (python 3.8)
git --version
# git version 2.25.1

Si vous obtenez une sortie similaire, tout c’est bien passé.

Maintenant nous allons installer le paquet pip virtualenv qui permet de séparer les environnements d’exécutions de vos différentes applications Python 3, avec la commande suivante, en tant qu’utilisateur :

pip3 install virtualenv

A ce moment là, il se peut que vous ayez un warning vous indiquant que le script est dans tel dossier et que celui-ci n’est pas dans la variable PATH.

Pour cela il faut éditer le fichier ~/.bashrc et injecter en fin de fichier la ligne suivante : PATH=$PATH:"CHEMIN_INDIQUE_DANS_LE_WARNING"

Puis appliquer les changements de ce fichier .bashrc en lançant la commande : source ~/.bashrc

Récupérons le code source de l’application

Pour cela en tant qu’utilisateur lancer la commande suivante dans votre dossier de travail : git clone https://gitlab.com/julienanne/django-deploy-production-example

Créons un environnement virtuel Pyhton3 pour notre projet Django

Entrer dans le dossier cd django-deploy-production-example/ et lancer la commande suivante en utilisateur afin de créer un environnement :

virtualenv monenv

Nous venons de créer un nouvel environnement pour notre projet il nous faut maintenant l’activer avec la commande :

source ./monenv/bin/activate

Ce qui devrait avoir pour effet de précéder votre prompt de terminal avec (monenv) cela indique que nous sommes dans l’environnement virtuel python3 se nommant « monenv ».

A partir de ce moment là vous n’aurez plus besoin de faire la commande pip3 pour accéder au gestionnaire de paquets Python3 mais simplement pip car virtualenv ayant été installé avec pip3, la commande pip dans un environnement virtualenv représente maintenant pip3.

Installons les dépendances Python de notre application Django

Pour cela rien de plus simple vu que nous avons figé les dépendances avec la méthode présentée dans ce tutoriel nous avons un fichier requirements.txt contenant tous les noms et les versions des packages pip à installer, il ne nous reste donc qu’à taper la commande suivante à la racine du projet en utilisateur :

pip install -r requirements.txt

Et vous verrez les différents packages s’installer automatiquement. Pour vérifier un petit pip list vous permettra de visualiser le résultat.

S’il n’y a pas de fichier requirements.txt dans votre projet il vous faut aller sur l’environnement où a été créé le projet afin de retrouver toutes les dépendances nécessaires ou suivre les différentes erreurs que vous trouverez lors de vos tests (c’est beaucoup moins marrant).

Lançons notre application afin de vérifier que tout est opérationnel

Pour lancer notre application rien de plus simple, il faut exécuter la commande suivante à la racine du projet : ./manage.py runserver

Pour vérifier que tout est ok il faut se rendre à l’url http://127.0.0.1:8000/, vous devriez voir le texte « Hello, world …. »

Ok donc à ce moment là nous avons un projet qui tourne sur notre poste de développement, vous pouvez donc maintenant le faire évoluer… Passons à la suite. Rendez-vous sur le sommaire du tutoriel pour continuer votre lecture.

Image par Jiradet Inrungruang de Pixabay