J’ai commencé à publier sur Medium il y a un peu plus d’un an.
Choisir Medium pour commencer mon blog était une excellente décision.
Mais j’ai décidé de quitter cette plateforme et je t’explique pourquoi sur mon nouveau blog.

Je t’ai déjà parlé de cette étude dans un précédent article qui expliquait comment automatiser la détection de vulnérabilités. Tu noteras au passage que l’année dernière seuls 60% des projets contenaient au moins une vulnérabilité. Je n’ai pas suffisamment de détails pour expliquer cette hausse. Au delà du nombre précis ce qui est important c’est de se demander ce que l’on peut mettre en place pour prévenir les risques que cela entraîne. Je pense qu’une bonne approche peut se résumer au moyen de ses deux stratégies :

• Rester constamment à jour
• Éviter les gros changements de type big-bang au profit de mise à jour plus ciblées

Il se trouve que j’ai découvert récemment un outil, Dependabot, qui permet d’automatiser la mise à jour de ces dépendances. Je vais te le présenter dans cet article.

Présentation Générale

Dependabot est une application GitHub qui va accéder à tes repos au moyen d’un access token. Chaque jour, elle analyse tes fichiers de dépendances et recherche celles qui peuvent être mise à jour. Si l’une des dépendances est obsolète, Dependabot ouvre un Pull Request pour la remplacer. Il te reste alors à vérifier l’exécution des tests, analyser le changelog de la bibliothèque et prendre une décision. Accepter la mise à jour en mergeant la PR ou ignorer la nouvelle version.

Ce que je trouve intéressant c’est la variété des langages supportés. On retrouve des langages de backend populaires tels que Javascript, Java et PHP. Mais aussi des langages moins répandus tels que Go, Rust ou encore Elixir.

Quelques Exemples

Afin de rédiger cet article j’ai pris le temps de tester l’outil sur plusieurs projets. Un projet en Java/Maven et un projet en Go. Ces deux stacks techniques sont disponibles respectivement en beta et en alpha. Cela c’est un peu ressenti à l’usage.

Un exemple de PR

Pour ce premier exemple je te montre une PR ajoutée par le bot pour un projet en Go. Comme pour toute PR il est possible de consulter la liste des fichiers modifiés :

Habituellement cela permet de comprendre l’impact des changements de code. Dans le cas d’une mise a jour de dépendance pas tant que ça. Et c’est là que l’outil est bien conçu ! Dans la description de la PR vont être renseignées trois informations. Tout d’abord les release notes, qui indiquent les changements majeurs de la version. Ensuite la liste des commits, cela permet d’avoir une information plus détaillée. Enfin, un score de comptabilité est aussi mentionné.

Comment est calculé ce score ? C’est très simple. Lorsqu’une nouvelle version de dépendance est publiée, Dependabot crée des PRs similaires sur des centaines de dépôts. Pour chaque repos avec l’intégration continue d’activée, Dependabot détermine si la mise à jour casse des tests. Le score de compatibilité est le pourcentage d’exécutions de CI qui ont réussies la mise à jour entre les versions concernées.

Clôture automatique des PRs obsolètes

Une des autres fonctionnalités que j’ai trouvé pratique c’est la clôture automatique des PRs obsolètes. Dans l’exemple ci dessus une version 0.26.0 venait d’être publiée. Le bot a donc automatiquement clôturé la PR concernant la version 0.25.0. Cerise sur le gâteau un commentaire indique que la PR est remplacée par une autre, en proposant un lien vers cette nouvelle PR.

Clôture sans raison

J’ai malheureusement constaté certaines incohérences dans le fonctionnement du bot. Par exemple j’ai vu une PR se voir clôturer sur le projet utilisant Maven.

Ici le bot commente en disant que la dépendance ne peut plus être mise à jour. Ce comportement est apparu après avoir approuvé une autre PR sur ce même repo. Pourtant la dépendance est actuellement en version 2.0.16 et il est donc possible de la mettre à jour.
Dans ce cas j’ai interagis avec le bot en commentant la PR. Tout t’abord pour la réouvrir, puis pour effectuer un rebase. C’est justement une des forces de l’outil, la possibilité de pouvoir interagir avec le bot directement dans la PR. Malheureusement cela n’a pas suffit. La PR était systématiquement refermée par le bot. L’outil étant en version beta pour les projets Maven, il n’est pas surprenant que quelques bugs puissent exister.

Besoin d’un petit coup de ménage

Sur un des projets en Go j’ai aussi constaté un comportement lacunaire. Suite à la mise à jour de testify, une dépendance transitive n’a pas été supprimée. Si j’ouvre le projet avec Visual Studio Code je constate un warning :

C’est d’autant plus dommage que c’est trivial à corriger. Si je tape la commande suivante :

go mod tidy

Le fichier go.mod est alors nettoyé. La dépendance transitive “gopkg.in/yaml.v2 v2.2.8” est supprimée.

Configuration Avancée

Il est possible de configurer plus finement le bot. Pour cela on utilise un fichier dependabot.yml, au format YAML donc. Il est nécessaire de placer ce fichier dans le repertoire .github du repo.

Les options disponibles concernent la fréquence des vérifications, le nommage des PRs, la stratégie de rebase et bien d’autres. Je te laisse consulter la documentation officielle pour obtenir une liste exhaustive.

Déployer sa propre instance

Les gestionnaires de sources actuellement compatibles avec Dependabot sont : GitHub, GitHub Enterprise, GitLab et Azure Devops. D’autre part je pense que certaines organisations peuvent être frileuses à l’idée d’autoriser l’accès à leur code source à un outil en ligne. Pour palier à ces limitations il semble qu’il soit possible de déployer sa propre instance de Dependabot.

Le projet étant implémenté en Ruby il faut compiler le projet puis le déployer. Pour faire fonctionner Dependabot et utiliser l’ensemble des langages supportés, tu auras besoin d’installer Ruby, Python, PHP, Elixir, Node, Go, Elm et Rust. Cependant, si tu souhaites l’utiliser pour un seul langage, tu peux te contenter d’installer ce langage ainsi que Ruby.

Autre possibilité : Docker. Bien qu’il soit possible de déployer Dependabot sans utiliser Docker, c’est l’approche recommandée par les concepteurs du projet. En effet l’image Docker contient déjà toutes les dépendances pour pouvoir utiliser les différents langages supportés. Je n’ai personnellement pas déployé ma propre instance. Je ne peux donc pas te dire si c’est rapide à réaliser.

Considérations diverses

Avant de conclure cet article je voudrais partager quelques remarques. Tout d’abord la nécessité des tests. Pour pouvoir utiliser cet outil avec confiance, il faut une base de code avec des tests. Plus encore, il faut une couverture de tests suffisantes. Un build vert doit garantir que l’on n’aura pas de régressions en production. On entend parfois dire que les tests coûtent chers. Je pense d’une part que cela dépend de l’expérience des développeurs de l’équipe en la matière. Pratiquer le TDD quand on ne l’a jamais fait avant prend du temps. Quand on est habitué c’est quasiment sans incidence sur le temps de développement. D’autre part le léger surcoût est remboursé sur la durée. Pouvoir mettre à jour fréquemment ses dépendances et ainsi limiter la probabilité qu’une fuite de données ou un hack ait lieu, ce n’est pas du luxe !

Une autre considération est le nombre de mise à jour qu’un projet en moyenne aura chaque semaine avec Dependabot. Dans un billet de blog, GitHub nous explique qu’un projet Ruby compte en moyenne 125 dépendances. 38 sont directes et 87 sont des dépendances transitives. Un projet Ruby typique reçoit habituellement deux mises à jour de dépendances par semaine. Parmi ces mises à jour, 94 % ne cassent pas le build. Cela signifie qu’en moyenne, tu n’auras besoin d’écrire du code en réponse à une mise à jour de dépendance qu’une fois tous les deux mois. Le reste du temps, tu peux simplement cliquer sur “merge” et continuer à opérer avec des dépendances sécurisées et mises à jour.

Enfin, il faut savoir que Dependabot a d’abord été un projet indépendant de GitHub. L’acquisition par GitHub a été annoncée en milieu d’année 2019. Soit environ un an après le rachat de GitHub par Microsoft. Il est intéressant de constater les nombreux changements apparus depuis ce rachat. N’oublions pas que Microsoft est aussi un cloud provider. Les cloud providers tels que AWS, GCP et Microsoft Azure proposent fréquemment de nouveaux services DevOps (gestionnaires de code source, de chaînes d’intégration, etc…). Cette semaine par exemple AWS a présenté son outil AWS CodeArtifact. Il va donc être interessant de voir si les services additionnels de GitHub vont permettre à Microsoft d’améliorer Azure Devops et ainsi obtenir un avantage concurrentiel.

Si tu es arrivé jusqu’ici, merci beaucoup d’avoir lu cet article !
Si il t’a plu, pense à me laisser un clap et à me suivre.
N’hésite pas à me laisser un commentaire ou une question, directement en bas de cet article ou en m’envoyant un message sur LinkedIn.

Les blogs AWS

Qui mieux que AWS peut parler de AWS ? Question rhétorique je te l’accorde ! Depuis 2004 AWS publie des articles sur son blog officiel. Le blogueur le plus célèbre est probablement Jeff Barr. Chief Evangelist chez AWS, c’est lui qui a lancé le blog en 2004. Il a écrit des articles quasiment sans interruption depuis lors. Par la suite de nombreux autres contributeurs sont venus l’épauler dans cette tâche.

Ce que je trouve pratique avec ce blog c’est la quantité de filtres disponibles. Ces filtres permettent de trouver plus facilement le type de contenu que je recherche. Il est ainsi possible d’afficher les articles concernant uniquement un niveau de connaissance : débutant, confirmé ou expert. Autres possibilités, trier par produit ou solution : Compute, Lambda, DynamoDB, Intelligence Artificielle, etc…

L’autre page qui je visite régulièrement est What’s New with AWS. La plateforme cloud AWS se développe chaque jour. Cette page me permet d’en savoir plus sur les dernières annonces de produits, services et fonctions d’AWS.

La chaîne Youtube d’AWS

L’autre média privilégié par AWS pour communiquer avec ses utilisateurs est la vidéo. La chaîne officielle AWS propose un peu plus de dix mille vidéos à l’heure où j’écris cet article. Plusieurs formats sont proposés : cas client, présentation de produits et services. Ce que j’apprécie particulièrement ce sont les vidéos des conférences.

La plus connues d’entre elles est re:Invent, la conférence annuelle de AWS. Je visionne généralement les KeyNotes d’ouverture et de fermeture. Certaines sessions techniques sont aussi riches d’enseignement.

L’autre conférence que AWS organise est re:Inforce. C’est une conférence axée sur la sécurité dans le cloud. Pendant deux jours des problématiques telles que la gestion des identifiants, de la conformité ou encore de la détection de menaces sont abordées.

AWS This Week

Cette semaine une personne m’a demandé des conseils sur la meilleure manière de se préparer aux certifications AWS. Personnellement j’ai suivi les cours dispensés en ligne par A Cloud Guru. Je trouve que c’est bien conçu et que c’est agréable à suivre. Le résumé en fin de section permet de mieux mémoriser les connaissances. L’autre atout de cette plateforme est le simulateur d’examens. Je pense sincèrement que cela m’a fait gagner de précieux points à chaque fois.

Il se trouve que A Cloud Guru possède également une chaîne Youtube. Une des séries de vidéos que j’apprécie le plus est “AWS This Week”. Ces vidéos présentent les dernières annonces de AWS. On y retrouve les nouveaux produits et les nouvelles fonctionnalités sur les produits existants. Le format est relativement court, environ trois minutes.

Les livres blancs

L’autre source officielle d’information c’est les livres blancs. Certains sont très généraux comme par exemple “Overview of Amazon Web Services”. D’autres sont plus spécifiques comme par exemple “Power Machine Learning at Scale”. Il est à noter que pour chaque certification, AWS fournit une liste de livres blanc dont la lecture est recommandée.

Au-delà de se préparer aux certifications ces livres blancs me permettent d’approfondir mes connaissances. Je dois reconnaître que c’est parfois un peu indigeste à lire. J’évite donc de lire cela le soir avant de m’endormir ! Autres astuces, j’essaie d’être dans un endroit calme et je prends des notes pendant la lecture.

Reddit

Connais-tu Reddit ? C’est un réseau social, plus populaire outre atlantique qu’en France, mais dont l’adoption augmente depuis peu en France. Pour faire simple c’est un meta forum, c’est à dire un forum regroupant une myriade de sous-forums nommés subreddits. On y trouve du contenu de divertissement mais aussi des subreddits techniques. Parmi ceux-ci on compte le subreddit dédié à AWS.

On y trouve différents contenus. Des personnes qui demandent de l’aide par exemple, les réponses proposées sont souvent instructives. Certains utilisateurs postent aussi des liens vers des articles de leur blog ou des vidéos de leur chaîne. Régulièrement on retrouve même des posts de Jeff Barr himself ! Bref si tu ne connais pas encore je te conseille d’aller y faire un tour !

Si tu es arrivé jusqu’ici, merci beaucoup d’avoir lu cet article !
J’espère qu’il t’a plu ?
N’hésite pas à me laisser un commentaire ou une question, directement en bas de cet article ou en m’envoyant un message sur LinkedIn.
Je suis curieux de savoir quels sont les sujets qui t’intéresse et comment tu fais ta veille ?

J’ai donc élaboré une liste de réalisations pour cette année. Je me suis dit que ça pourrait t’intéresser d’en connaître le contenu. Je vais donc te la détailler aujourd’hui. Avant cela je vais t’expliquer comment je l’ai rédigé et comment je la décline au cours de l’année.

L’enthousiasme comme carburant

La plupart des listes d’objectifs ont un problème majeur. Leur formulation. “Il faut que je fasse X cette année”. Cela en fait une liste d’impératifs. Ça devient vite une contrainte plutôt qu’un plaisir. Quand j’ai écouté l’épisode 29 de Tribu Indé je me suis dit que je tenais une bonne formulation. L’idée c’est de compiler une liste de réalisations qui nous font envie.

L’enthousiasme est une formidable source de productivité. Quand je travaille sur quelque chose qui m’électrise je vois ma motivation déborder. Je vais plus vite. J’ai envie d’aller plus loin. J’ai envie d’approfondir le sujet sur lequel je travaille. J’ai donc essayé de garder cela en tête afin de définir mes objectifs.

Une déclinaison sur 90 jours

Une fois mes quatres objectifs définis je les décline sur des périodes de 90 jours. Cela donne donc quatre périodes dans une année. Cela permet d’avoir de la diversité durant cette année. Je peux ainsi décider de travailler principalement un objectif au premier trimestre puis de le mettre en arrière-plan le trimestre suivant.

Cela donne aussi de la souplesse et la possibilité de réajuster mes objectifs tous les trois mois. La fameuse agilité ! En fonction des événements il peut-être intelligent de supprimer un objectif et de le remplacer pour un autre. Autre possibilité, réduire à la hausse ou à la baisse un objectif en fonction des opportunités. C’est par exemple le cas des conférences (j’en parle un peu plus bas). Actuellement la quasi totalité des conférences sont annulées et il ne m’est pas toujours possible d’y assister en ligne.

Amazon Web Services

Depuis un peu plus d’un an, j’ai décidé de me spécialiser dans le cloud AWS. J’aurais pu aussi choisir Azure ou GCP. L’entreprise où je travaillais à cette époque utilisait exclusivement AWS. D’où ce choix. Une fois lancé je trouve plus intéressant de connaître une plateforme en profondeur plutôt que d’avoir des connaissances superficielles sur plusieurs plateformes. De plus on retrouve des services similaires sur ces trois plateformes. Par exemple GCP Cloud Storage et Azure Blob Storage sont quasi équivalents à AWS S3.

Une des approches qui fonctionne pour moi et de passer des certifications. C’est un peu comme pour la course à pied. Quand je me suis inscrit au semi-marathon Saint-Pol-Morlaix j’ai enfin réussi à aller courir régulièrement. Avoir une épreuve cible me permet de me motiver. Cette année je veux donc passer quatre certifications AWS.

C’est plutôt en bonne voie car je viens de passer deux certifications du niveau associate : Developer Associate et SysOps Administrator Associate. Pour la suite je vais probablement attaquer des certifications de type Specialty. J’hésite encore entre Networking et Security ou quelque chose de plus fun comme Alexa Skill Builder et Machine Learning.

Open-source & Go

Il n’y a pas longtemps je te parlais de certaines de mes contribution open-source. Cette année j’ai envie de contribuer encore plus. Je t’ai aussi expliqué que j’avais appris le langage Go l’année dernière. Je souhaite aussi accumuler de l’expérience avec Go. Idéalement j’ai donc envie de contribuer à un ou plusieurs projets open-source en Go cette année.

Pour l’instant je n’ai pas fait suffisamment de progrès sur cet objectif. J’ai bien conçus un outil pour gérer mon budget en Go que j’ai open-sourcé. J’ai aussi effectué quelques contributions en Java et Python. En vérité je ne pense pas être en mesure d’avancer beaucoup non plus dans les trois mois à venir. Mais l’année n’est pas terminée !

Meetup & Conférences

J’ai envie d’assister à trois conférences cette année. J’ai déjà eu le plaisir d’assister au DevFest du Bout du Monde fin février. J’avais envisagé de me déplacer à Paris pour assister à DotGo. Malheureusement l’épidémie de Covid-19 a eu raison de l’événement. Un événement est prévu dans les Côtes d’Armor en septembre, j’ai prévu d’y aller également. Bien évidemment tout cela dépendra de l’évolution de la situation sanitaire.

Je rêve aussi d’assister à Re:Invent, la conférence d’AWS à Las Vegas. Mais cela est un tout autre budget. Il y a le prix du ticket, du billet d’avion et de l’hôtel. Au total je pense que c’est 4000 ou 5000 dollars. Dans un tout autre style j’aimerais bien aussi assister à une non conférence comme Socrates Rennes. Si ça t’intéresse il y a un chouette compte-rendu sur le blog de Avalon-Lab.

J’aime beaucoup assister à des conférences. D’une part cela permet de découvrir de nouveaux outils et des nouvelles façons de penser. Je pense qu’une des habitudes importantes en tant que développeur c’est de questionner ses connaissances. Nos connaissances peuvent devenir obsolètes en seulement quelques années. Tout évolue en permanence. Les langages. Les frameworks. Les architectures. Enfin ces événements sont l’occasion de rencontrer des personnes. Parfois les discussions qui suivent sont tout aussi intéressantes que la conférence en elle même. Tous ses avantages sont aussi valables pour les MeetUps. J’essaie d’assister aussi régulièrement que possible aux MeetUps de la région Brestoise. En particulier FinistDevs et BrestJS.

Création de Contenu

Enfin le dernier axe sur lequel je veux travailler cette année c’est la création de contenu. J’ai commencé l’année par me focaliser principalement sur ce blog. J’ai donc commencé par écrire un article par semaine pendant les trois premiers mois de l’année. Cela m’a permis d’expérimenter et de trouver des habitudes. Je vais continuer à alimenter ce blog dans les semaines à venir.

Je m’intéresse aussi au format vidéo. Je pense qu’il est plus adapté à certains sujets d’une part et d’autre part je pense qu’il permet de capter une audience plus large. Cela demande toutefois plus de travail. Je suis en réflexion actuellement à la fois sur le fond et sur la forme. Je souhaite adopter un format assez dynamique, c’est à dire un assemblage de différentes vues et plans. Je me fais actuellement la main avec des vidéos des enfants que je partage avec la famille pendant ce confinement. Cela me permet d’expérimenter différents cadrages et de me faire la main sur le logiciel de montage.

Si tu es arrivé jusqu’ici, merci beaucoup d’avoir lu cet article !
J’espère qu’il t’a plu ?

Si l’on résume voici mes quatres objectifs pour 2020 :

• Développer une expertise AWS
• Contribuer plus à l’open-source et en particulier en Go
• Assister à plus de conférences et Meetups
• Créer du contenu : blog et vidéos

Je t’encourage toi aussi à rédiger une liste d’objectifs. Que ce soit sur douze ou sur trois mois !
N’hésite pas à me laisser un commentaire ou une question, directement en bas de cet article ou en m’envoyant un message sur LinkedIn.

J’ai commencé à publier des articles sur Medium il y a un peu moins d’un an. Dix mois en fait. J’avais à l’époque publié un article sur les assertions dans les tests. J’ai continué à publier épisodiquement. En fonction de l’inspiration. Quand je pensais avoir le bon sujet et le bon titre je me posais sur mon clavier et en avant la musique !

En fin d’année je me suis dit que ça serait une bonne idée d’accélérer la cadence. Plus d’articles. Plus souvent. Je me suis donc lancé dans un challenge : écrire un article par semaine pendant trois mois. Aujourd’hui je te raconte la genèse de ce challenge et ce que j’ai appris en cours de route.

Mes inspirations

Ma principale inspiration pour cette aventure est Alexis Minchella et son podcast Tribu Indé. J’ai commencé à l’écouter il y a un peu plus de six mois je crois. Un peu par hasard. Puis je me suis abonné sur Apple Podcast et j’ai écouté régulièrement les nouveaux épisodes.

Un des thèmes récurrents dans ce podcast est la création de contenu. Ce n’est pas surprenant quand on sait que Alexis Minchella est freelance en content marketing et copywriting. La création de contenu offre de multiples avantages, en particulier pour les freelances. Est-ce alors réservé aux freelances ? Non. Je ne le crois pas. J’ai donc voulu m’y mettre à mon tour.

Mes objectifs

Je me suis donc fixé comme objectif de rédiger et publier un article par semaine pendant trois mois. Pourquoi trois mois ? Quand on se lance dans un challenge il y a d’abord une phase d’excitation. Pendant trois à quatre semaines. Puis ça s’estompe. Partir sur trois mois me permet donc de traverser cette période de baisse de motivation.

Le fait de devoir le faire une fois par semaine me force aussi à publier : même quand je pense ne pas avoir grand-chose à raconter, même quand je ne suis pas parfaitement satisfait de mon article et même quand je ne suis pas extrêmement motivé.

Tout cela peut sembler contraignant. Pas fun. Sauf que je me suis lancé ce challenge avant tout par que cela m’amusait. Je me suis d’ailleurs inspiré de l’épisode 29 de Tribu Indé pour rédiger mes objectifs pour 2020. Dans le cas du contenu cela se résume à : “J’ai envie de publier un article par semaine”.

Quels résultats escomptés ?

Avec ce challenge je souhaitais obtenir deux résultats : améliorer mon expression écrite et partager avec la communauté des développeurs.

Je pense que l’écriture est un muscle. En publiant régulièrement je travaille ce muscle. Et c’est un muscle utile ! Il y a beaucoup de stéréotypes qui circulent au sujet des développeurs. Mais être capable de communiquer et s’exprimer efficacement est une compétence cruciale. Au final on passe presque plus de temps à échanger qu’à coder.

D’autre part je souhaitais apporter ma modeste contribution à la communauté des développeurs. La majeure partie de ce que je connais, je l’ai appris en ligne. Et ce sur une kyrielle de plateformes : StackOverflow, les blogs, Dev.to, etc… Je pense que c’est un juste retour des choses de partager à mon tour mes aventures dans le monde du code. On ne sait jamais, si cela peut aider ne serait-ce qu’une personne par article cela me convient parfaitement !

Show Your work

Un des livres que j’ai découvert en cours de route est Show Your Work. Encore une fois j’en ai entendu parler dans un des épisodes du podcast. L’idée est qu’il est plus important de partager son travail en cours que d’attendre d’avoir confectionné une œuvre d’art pour le partager.

Cela peut être un changement de posture salvateur. En effet, au lieu de se positionner en tant qu’expert on se positionne en tant que curieux. Passionné. On documente alors le chemin que l’on suit dans la découverte de cette passion. Il devient dès lors plus aisé de publier du contenu. C’est d’autant plus important pour les personnes souffrant du syndrome de l’imposteur.

Résultats obtenus

Un des plus grands avantages à avoir partagé en ligne mes expériences et connaissances c’est les commentaires que je reçois. Cela me permet d’approfondir le sujet traité. De découvrir des alternatives. Certaines questions me permettent aussi de me remettre en question. Parfois c’est aussi un simple bravo ou merci, cela fait toujours plaisir ! Par conséquent je vais essayer de moi-même commenter plus souvent sur les contenus que je consulte.

Devoir écrire un article sur un sujet en particulier m’oblige aussi à réviser. Ainsi, j’ai souvent besoin de comprendre pourquoi je fais les choses de telle manière afin de pouvoir l’expliquer au mieux. Le simple fait d’écrire me fait progresser dans la maîtrise technique d’un framework, d’un langage ou d’un outil. Je me suis même demandé s’il était possible d’écrire un article sur un sujet que je ne connais pas ? Faire un travail de recherche et ensuite en rédiger une synthèse. Ça pourrait être un challenge fun pour le futur !

L’écrit, est-ce un bon média ?

Je suis globalement satisfait d’avoir mené à bien ce défi. Je pense que le format article de blog est un bon choix car il permet de se lancer rapidement. Pas besoin de matériel coûteux, un simple laptop avec accès à internet suffit. De plus avec Medium il n’est pas nécessaire de se payer un serveur, d’y installer WordPress et de passer plusieurs heures sur de la configuration. Ceci dit, Medium souffre de quelques défauts. Le paywall en particulier. A moyen terme je pense migrer mes articles vers un blog dédié. Mais pour l’instant je souhaitais me focaliser sur la création de contenu.

Malgré cette satisfaction globale, je trouve que pour certains articles ce média n’est pas adapté. Par exemple les articles qui traitent de la configuration de Jenkins. On remarque d’ailleurs que j’y ai inséré des gifs avec un enregistrement de mon écran. Des vidéos ! Quel intérêt alors de mélanger texte et vidéo ? Limité. D’autant que les gifs ne sont pas d’excellentes qualités. Pour ce genre de ce sujet je pense qu’il est plus intéressant de partir sur un format vidéo dès le départ.

Et maintenant ? Quelle suite je vais donner à ce challenge ? Je vais assurément continuer à publier des articles. Ceci dit je pense ralentir un peu le tempo. Probablement en tablant sur deux articles par mois. J’envisage aussi de créer des vidéos, en particulier sur les sujets les plus techniques. Mais cela demande de l’organisation. Je vais donc attendre encore un peu.

Si tu es arrivé jusqu’ici, merci beaucoup d’avoir lu cet article !
J’espère qu’il t’a plu.
N’hésite pas à me laisser un commentaire ou une question, directement en bas de cet article ou en m’envoyant un message sur LinkedIn.

J’ai remarqué que de nombreux développeurs hésitaient à faire leur première contribution open-source. C’est peut-être ton cas ? C’est plus facile que ça en a l’air. Comme pour beaucoup de choses l’étape la plus difficile est d’enclencher la machine. Une fois la première contribution accomplie, puis les deux ou trois suivantes ça devient plus simple. Mon conseil par conséquent est de choisir une première tâche relativement aisée afin de lancer la dynamique.

A travers mon expérience personnelle, expérience de développeur non expert en open-source, je vais te présenter des exemples de contributions que j’ai effectuées ces derniers mois. Tu trouveras avec ces exemples un lien vers les Pull Requests afin que tu puisses regarder en détail les changements que j’ai proposés.

📝 Améliore la Documentation

Le premier type de contribution qui me semble accessible pour les débutants, c’est la documentation. Les développeurs ont parfois tendance à délaisser les tâches de documentation. Et pourtant c’est important pour la réussite de tout projet open-source. Si les utilisateurs ne trouvent pas de l’aide quand ils rencontrent des problèmes ils risquent d’arrêter d’utiliser l’outil.

Récemment je me suis aperçu que la documentation de l’image Docker officielle de Golang pouvait être amendée. J’utilise principalement cette image pour faire de l’intégration continue avec des projets en Go. Il se trouve que les exemples donnés dans la documentation utilisaient le tag d’une image relativement ancienne. J’ai donc mis à jour ces exemples pour qu’ils utilisent la dernière version disponible. Si tu souhaites en savoir plus, consulte la PR sur GitHub.

🇫🇷 Traduit en Français

Un autre besoin sur beaucoup de projets est l’internationalisation. En effet la plupart des projets sont d’abord implémenté avec une interface en anglais. Afin de favoriser une adoption plus large il est courant de vouloir adapter cette interface à d’autres langues.

Comme je le disais dans le paragraphe précédent j’utilise beaucoup Jenkins au quotidien pour effectuer de l’intégration continue. En préparant l’article sur le déploiement d’un serveur Jenkins sur AWS, je me suis aperçu que certaines parties de l’interface de Jenkins étaient en français et d’autres non. Je me suis donc mis au travail et j’ai proposé plusieurs PRs : ici, là ou encore ici.

Il y a un peu plus longtemps j’ai découvert le projet Moment JS. La manipulation de dates est l’un de ces défis que nous devons tous relever à un moment donné de notre carrière de développeur, et l’utilisation du bon outil permet de dompter cette bête sauvage ! La bibliothèque Moment JS est ainsi l’outil de référence pour les développements JavaScript.

Depuis que je l’ai découvert, je l’utilise régulièrement pour simplifier la validation, l’analyse et la manipulation des dates côté client. Une myriade de langues étaient déjà supportées mais il manquait le support du Breton. J’ai donc rajouté ce support avec cette PR, puis corrigé un certain nombre de bugs avec cette autre PR.

🔬 Ajoute des Tests

Enfin la dernière catégorie de missions faciles à accomplir concerne les tests. Personnellement je teste systématiquement mes développements. Soit en mode TDD, en écrivant d’abord les tests puis le code de production. Parfois j’avoue que j’écris mes tests après.

Sur les projets open-source il est parfois possible de trouver des portions de code qui ne sont pas testées. Concevoir des tests pour ces portions te permet alors de mettre un pied dans le projet. C’est ce que j’ai fait sur le projet Prometheus par exemple avec cette PR. J’aurais souhaité en profiter pour contribuer un peu plus sur ce projet, projet que j’utilise constamment, mais pour l’instant je n’ai pas trouvé le temps de le faire.

🤝 Un projet que tu utilises

Tu as peut-être remarqué une tendance parmi les exemples que je t’ai présentés, il s’agit à chaque fois d’outils que j’utilise au quotidien. Il est en effet plus facile je trouve de contribuer à des projets dont on est utilisateur. Je t’encourage donc à regarder d’abord les projets que tu utilises toi et à rechercher des choses à améliorer ou à corriger. D’une part il te sera plus facile de tester tes modifications car tu connais déjà l’interface ou les commandes. D’autre part cela est un juste retour des choses, si tu profites d’un projet libre il est légitime que tu finances cette utilisation par une contribution.

🔎 Identifie des tâches pour débutant

Enfin je voulais te parler d’une manière de trouver facilement des tâches pour débutant sur GitHub. J’ai découvert cette astuce lors d’un événement local organisé dans le cadre du Hacktoberfest. Il est courant d’attribuer le tag “Good First Issue” aux tâches accessibles aux débutants. Par exemple en ouvrant cette page https://github.com/issues?q=label%3A%22good+first+issue%22+is%3Aopen tu peux consulter toutes les tâches ouvertes.
Si tu connais déjà le projet qui t’intéresse tu peux aussi rajouter “contribute” dans l’url. Par exemple en ouvrant la page https://github.com/vuejs/vue/contribute tu vois toutes les tâches du projet VueJS.

Pour en savoir plus je t’invite à consulter cette page du blog GitHub : https://github.blog/2020-01-22-browse-good-first-issues-to-start-contributing-to-open-source/

J’espère que cet article t’a plu et qu’il t’a motivé à faire ta première contribution. N’hésite pas à me laisser un commentaire ou une question, directement en bas de cet article ou en m’envoyant un message sur LinkedIn.

Merci à Vincent qui nous a présenté à Genesys il y a quelques semaines son expérience de contributeur. Merci à Antoine pour sa question ce jour là qui a en partie inspirée cet article.
Merci également à Cyrille avec qui j’ai discuté récemment de mon souhait de contribuer à des projets en Go et dont certains conseils se retrouvent dans cet article.

Le 28 février dernier a eu lieu le DevFest du Bout du Monde à Brest. Je n’avais pas pu y assister l’année dernière et cette année j’ai donc pris mes billets très en avance. C’est une chance de pouvoir avoir une conférence de cette importance en Basse-Bretagne et surtout pour un prix aussi modique. Il me semble que le ticket est à 40 € et ayant bénéficié du tarif pre-early bird je l’ai eu pour 20 €. Je vous propose donc de faire un résumé de cette journée, résumé qui sera forcément subjectif car je n’ai pas pu assister à tous les talks, il y avait quatre tracks en parallèle.

Le thème de cette édition était Skynet vs Asimov. J’ai demandé l’aide d’un collègue pour m’expliquer les concepts car ne regardant pas la télévision je ne connaissais pas Asimov et je savais vaguement que Skynet était une référence à Terminator. Heureusement la keynote d’ouverture m’a permis d’y voir plus clair, il s’agissait de réfléchir à la place que l’on souhaite accorder aux robots et plus généralement au code dans notre société. Les développeurs ont une responsabilité dans l’évolution que va suivre notre société, soit une société coercitive et aliénante ou au contraire une société plus libre grâce aux possibilités qu’offre la technologie et les logiciels.

Au niveau des talks en eux même, j’ai trouvé qu’il y avait une grande variété, certains étant très technique d’autres un peu plus théorique. J’ai particulièrement aimé le premier talk de la journée qui s’intitulait “Et si le design était l’affaire de tous”. Le sujet portait sur l’UX design et la place qu’on y accorde dans les équipes. Cela m’a fait penser au changement qui s’est opéré il y a quelques années où l’on a souhaité rapprocher les développeurs et les testeurs. Il faut maintenant favoriser la collaboration entre les UX designers et le reste de l’équipe. Au-delà de l’aspect purement théorique, de nombreux outils ont été présentés (6-to-1, moodboard, etc.). Parmi les autres talks que j’ai appréciés il y avait un sur le monitoring d’API, un sur l’utilisation de Bazel et un autre sur le functional programming. Toutes ces présentations devraient être disponibles prochainement sur YouTube.

Au niveau de la logistique j’ai trouvé que c’était extrêmement bien organisé. Le lieu, l’UBO, est particulièrement adapté à ce type d’événement. D’autre part, nous avons eu largement de quoi nous sustenter tout au long de la journée. Mention spéciale pour le choix de ne pas distribuer de goodies cette année et utiliser l’argent ainsi économisé pour soutenir des initiatives telles que la Quadrature du Net. Étant dans une démarche zéro déchet j’apprécie grandement ce type d’initiative. Je pense qu’il est possible d’aller encore plus loin par exemple au niveau des gobelets de type ecocup qui pourrait être loués.

Enfin la keynote de fermeture nous a présenté le FabLab de l’Université de Brest et toutes les initiatives qui y ont lieu. C’était vraiment passionnant et je n’étais pas au courant de tous ces projets. Nous avons aussi eu une annonce, à savoir l’organisation d’une conférence dans les Côtes-d’Armor en septembre prochain. J’ai très hâte d’y assister !

Pour conclure et répondre à la problématique de cette journée à savoir Skynet ou Asimov, je suis de nature optimiste alors sans hésiter je choisis Asimov. Je suis convaincu la technologie va nous aider à construire une société plus ouverte et plus juste, mais pour cela il faudra rester vigilant, dénoncer les abus et prendre les bonnes décisions au quotidien !

J’espère que cet article vous a plu !
N’hésitez pas à me faire part de vos commentaires ou questions en bas de cet article ou en m’envoyant un message sur LinkedIn :
http://www.linkedin.com/in/jbleduigou/en

J’avais prévu de parler d’un tout autre sujet mais ma banque vient de mettre à jour son application de banque à distance et ça m’embête. Il faut dire que l’interface était vieillotte et il était grand temps de faire quelque chose. Dans la nuit de mardi à mercredi elle a déployé une nouvelle version de son application. Je n’ai pas encore eu le temps de tester toutes les fonctionnalités et je ne pourrai donc pas commenter l’ergonomie. Toutefois je trouve que le look est plus moderne et cela donne envie d’utiliser cette application.

Vous vous demandez donc pourquoi je suis mécontent si je trouve que l’interface est plus jolie ? Il se trouve que j’ai développé une application me permettant de suivre mes dépenses et ainsi mieux gérer mon budget. Pour ce faire j’utilise l’application de banque en ligne afin de télécharger un relevé de mes opérations au format CSV. Avec la mise à jour de l’application le format des données de ce fichier a été modifié. Cela casse la rétrocompatibilité et de ce fait mon application ne fonctionne plus. Si je vous parle de cela aujourd’hui c’est que je trouve que c’est un exemple de ce qu’il faut éviter quand on expose des données via une API ou tout autre méthode.

Afin que vous compreniez mieux la situation je vais vous présenter rapidement l’architecture de mon application. C’est une architecture serverless déployée sur le Cloud AWS. Après avoir téléchargé mon fichier CSV je le dépose sur un bucket S3, ceci déclenche l’exécution d’une lambda qui parse le fichier et attribue une catégorie à chaque transaction. Les transactions sont ensuite poussées individuellement dans une file d’attente SQS, chaque message déclenche à son tour l’exécution d’une deuxième lambda qui va écrire la transaction dans un fichier Google Sheets. Ceci me permet à la fin du mois d’avoir un listing complet de mes dépenses et de pouvoir vérifier le total par catégorie.

Venons-en aux modifications du format de données. Tout d’abord il y a l’extension du fichier qui avant était en majuscule et maintenant est en minuscule. Ce n’est pas le problème principal car il suffit de mettre à jour le déclencheur dans la configuration de la lambda pour régler le problème. A l’intérieur du fichier plusieurs surprises, dans la version précédente une ligne de débit contenait quatre champs délimités par un point-virgule tandis qu’une ligne de crédit contenait cinq champs délimités par un point-virgule. Je me basais sur cette différence pour pouvoir faire la différence entre les différents types de ligne. Maintenant toutes les lignes contiennent cinq champs, toujours délimités par un point-virgule. D’autre part le libellé des opérations est maintenant en majuscule alors qu’avant seule la première lettre de chaque mot était en majuscule. Je constate d’ailleurs que sur les applications web et mobile c’est également le cas, je trouve cela dommage car moins lisible. Enfin il y a une chose qui aurait pu être modifiée mais qui ne l’a pas été. Le fichier CSV est au format windows-1252 alors que j’aurais préféré qu’il soit au format UTF-8.

Au final je devrais pouvoir survivre, j’ai commencé à mettre à jour l’application et le bon découpage des classes au sein cette application me permet d’avancer rapidement. Ce qui m’intéresse le plus c’est d’imaginer comment cela aurait pu être évité. La première des choses c’est que personne n’est probablement au courant de l’utilisation que je fais de cette fonctionnalité d’export. Ensuite cet exemple montre qu’une erreur dans votre API sera parfois exploitée par vos utilisateurs comme une fonctionnalité, ici le fait que certaines lignes n’ont pas le même nombre de champs que les autres. Une fois l’erreur exposée il devient difficile de la corriger car certains clients risquent de s’en plaindre. Enfin l’exposition de données à travers un format CSV aurait pu être remplacée par une API de type REST. Cela permet par exemple mieux sécuriser les échanges en mettant en place une authentification de type Oauth2. De plus l’utilisation du versionning d’API permettrait potentiellement de casser la rétrocompatibilité sur une nouvelle version mais de continuer à exposer l’ancienne version.

En définitive cette péripétie me donne l’occasion de réfléchir à la conception des APIs et à leurs utilisations. Je pense qu’à l’avenir les clients d’un fournisseur de services en ligne augmenteront les fonctionnalités possibles en passant par des application tierces. C’est déjà le cas dans certains domaines d’activités mais je pense que cela va se généraliser à tous les domaines. Il est donc important de bien concevoir ses APIs afin de catalyser cette utilisation possible.

J’espère que cet article vous a plu !
Le code de mon application est sur GitHub : https://github.com/jbleduigou/budgetcategorizer
La PR qui m’a permis de fixer le problème : https://github.com/jbleduigou/budgetcategorizer/pull/6
N’hésitez pas à me faire part de vos commentaires ou questions en bas de cet article ou en m’envoyant un message sur LinkedIn :
http://www.linkedin.com/in/jbleduigou/en

Le Design Thinking a réussi à se répandre dans le monde du business ces dernières années et en particulier dans les entreprises de la tech. On ne compte plus les billets de blog, les conférences et talks à ce sujet.
Enième buzzword ou véritable instrument d’innovation ? J’ai voulu en savoir plus en lisant le livre de Roger Martin : The Design of Business, Why Design Thinking is the Next Competitive Advantage.

Première surprise, le livre a été publié en 2009. Le Design Thinking n’est donc pas une approche si récente. Cela explique aussi en partie l’aspect théorique du livre, qui traite plus du dilemme qui a poussé à formaliser le Design Thinking que de la mise en pratique de cette discipline.

Quelle est donc la thèse défendue par l’auteur ? Aujourd’hui, la plupart des entreprises ont l’envie d’innover. C’est même devenu un impératif, quand on sait par exemple que la durée de vie moyenne des entreprises établie au S&P 500 est passée sous les 15 ans. Elles aspirent à proposer une innovation qui change la donne, imaginer le nouvel iPhone ou inventer le prochain Tik Tok. Beaucoup font de réels efforts pour être innovantes, mais elles obtiennent des résultats décevants. D’après Roger Martin l’approche managériale classique dans les entreprises, consistant à favoriser la pensée analytique au détriment de la pensée intuitive, les empêche de se réinventer.

Il présente alors un concept d’entonnoir de la connaissance comme un processus suivi par les entreprises pour innover plus efficacement. L’entonnoir de la connaissance comporte trois phases différentes :

• Le Mystère (Mystery) : le mystère est un problème qui doit être résolu, un problème que les clients de l’entreprises rencontrent au quotidien.
• L’Heuristique (Heuristic) : l’heuristique est une règle empirique qui propose une solution au problème posé par le mystère.
• L’Algorithme (Algorithm) : pour obtenir l’algorithme l’heuristique est transformée en une formule fixe, favorisant ainsi la simplicité et l’efficacité.

Le passage du mystère à l’heuristique repose sur la pensée intuitive tandis que le passage de l’heuristique à l’algorithme s’appuie sur la pensée analytique.

Par conséquent la grande majorité des entreprises suivent une trajectoire commune. L’entreprise naît d’un acte créatif qui convertit un mystère en une heuristique par la pensée intuitive. Elle affine ensuite cette heuristique grâce à la pensée analytique et entre dans une longue phase où la gestion de l’entreprise domine. Au bout d’un moment, un concurrent se penche sur le mystère qui a fourni l’étincelle à cette entreprise, trouve une heuristique plus puissante et supplante l’entreprise d’origine, et ceci malgré l’avantage compétitif que procure l’efficacité de l’algorithme existant.

D’après Roger Martin il est nécessaire de trouver un équilibre entre pensée analytique et pensée intuitive afin de déceler de nouvelles heuristiques pour les mystères existants et peut-être aussi dénicher des mystères alternatifs. Il prend exemple sur Procter & Gamble, le Cirque du Soleil et RIM afin d’illustrer son propos.

Néanmoins j’ai été un brin déçu par le côté trop théorique de ce livre. J’aurais apprécié d’avoir plus d’exemples concrets de mise en oeuvre du Design Thinking. J’ai aussi trouvé qu’il y avait beaucoup de répétitions, en particulier le principe de l’entonnoir de la connaissance qui est ressassé tout au long du livre. D’autre part, j’ai trouvé que le langage utilisé était trop littéraire. Ayant passé trois ans dans des pays anglophones je pense maîtriser correctement l’anglais et pourtant j’ai buté sur plusieurs mots tout au long de la lecture. Le fait de devoir rechercher la définition de ces mots casse un peu la dynamique de la lecture et estompe un peu le plaisir de lire.

Au final je pense que c’est un bon livre pour se mettre sur la voie du Design Thinking et comprendre la genèse de ce paradigme. Il demande toutefois à être complété par une approche plus axée sur la pratique, comme un atelier par exemple.

J’espère que cet article vous a plu !
Si vous avez des ressources à me recommander sur le Design Thinking n’hésitez pas à me l’indiquer en laissant un commentaire en bas de cet article ou en m’envoyant un message sur LinkedIn :
http://www.linkedin.com/in/jbleduigou/en

L’intégration continue est une pratique de développement qui nécessite des développeurs qu’ils poussent du code dans un dépôt partagé plusieurs fois par jour. Chaque commit est ensuite vérifié par un build automatisé, ce qui permet aux équipes de détecter les problèmes à un stade précoce. En intégrant régulièrement, il est possible de détecter rapidement les erreurs et de les localiser plus facilement.

Je vous ai déjà présenté le serveur Jenkins dans d’autres articles : comment l’installer sur AWS et comment l’utiliser pour détecter des vulnérabilités. Il existe par ailleurs une multitude d’exemples en ligne pour mettre en place une CI pour des projets en Java ou Javascript.

Malheureusement les ressources sont plus rares concernant les projets implémentés en Go. Je vous propose donc de regarder dans cet article comment mettre en place un pipeline sous Jenkins pour compiler et tester une lambda implémentée en Go.

Golang, une brève introduction

Go, également connu sous le nom de Golang, est un langage de programmation compilé et statiquement typé. Le projet est porté par Google, qui l’a open-sourcé en 2009.

Go présente des similarités avec le C. Cependant, il améliore le C en ajoutant, entre autres, un mécanisme de garbage collection, le typage structurel et la sécurité de la mémoire.

Le langage de programmation Go a bénéficié d’un soutien croissant de la part des développeurs du monde entier, et il figure désormais en bonne place dans le classement “Most Loved, Dreaded, and Wanted” de StackOverflow :

Si vous souhaitez en savoir plus sur ce langage, j’ai écris un article en début d’année : “Apprendre le langage Go en 2020”

Préparation du serveur Jenkins

Afin de pouvoir compiler notre lambda nous allons avoir besoin d’une installation de Go. Plusieurs options s’offrent à nous : installer Go sur le serveur Jenkins, créer une nouvelle instance EC2 avec Go et la rattacher en tant que “slave” au serveur Jenkins, installer Docker sur le serveur Jenkins et utiliser une image Go pour notre pipeline. Je préfère partir sur cette dernière option.

Installer manuellement Go sur le serveur n’est pas forcément compliqué. En revanche avec la multiplication des projets à compiler on risque à la longue de se retrouver avec trop d’outils à installer et à maintenir.

L’utilisation de slaves est un bonne alternative pour éviter cela, en déployant un slave par type de projet. L’inconvénient est que d’une part cela complexifie le déploiement et d’autre part cela augmente la facture AWS à la fin du mois.

La dernière solution consiste à installer Docker sur le serveur Jenkins et ensuite à déployer un conteneur comme slave pour la chaque construction du projet. Cela permet de limiter le nombre d’outils installés sur le serveur tout en permettant de construire des projets de types variés. De plus il devient plus facile de construire un même projet sur différents runtimes cibles : Golang 1.13 et 1.14-rc par exemple.

L’installation de docker se fait à l’aide de ces commandes :

yum install docker -y 
usermod -aG docker jenkins
service docker start
sudo systemctl enable docker
service jenkins restart

La première ligne installe Docker depuis le gestionnaire de packets yum.
La seconde rajoute le groupe “docker” à l’utilisateur “jenkins”, afin que cet utilisateur puisse lancer des commandes docker.
La troisième ligne démarre le service Docker sur la machine.
La quatrième ligne indique au système de démarrer le service Docker à chaque redémarrage de la machine.
Enfin la dernière ligne redémarre le service Jenkins afin de prendre en compte les modifications de groupes/utilisateurs.

Si vous avez déjà un serveur Jenkins de déployé vous pouvez vous connecter à votre instance EC2 via SSH et taper ces commandes dans la console.
Si vous n’avez pas de serveur de déployé vous pouvez rajouter ces instructions dans le script d’initialisation que j’ai présenté dans cet article.

Première étape : la compilation

Nous allons donc créer un nouveau pipeline sur le serveur Jenkins. Cliquez sur “Nouveau Item”, saisissez le nom “budgetcategorizer”, sélectionnez “Pipeline” puis cliquez sur “OK”. Faites défiler le nouvel écran qui s’affiche puis en bas de la page renseignez le script suivant :

Cliquez sur “Sauver” et lancez le pipeline. Vous devriez obtenir un résultat qui ressemble à ceci :

Regardons les instructions du pipeline d’une peu plus près si vous le voulez bien.

Tout d’abord il y a l’instruction qui déclare l’agent sur lequel va s’exécuter la construction du projet :

agent {
  docker { image 'golang:1.13' }
}

Ici on déclare que l’on souhaite utiliser un container Docker qui se basera sur l’image “golang:1.13”. On comprend qu’il est possible de basculer vers une autre image en changeant cette ligne, par exemple en remplaçant “1.13” par “1.14-rc”.

Ensuite il y a trois variables d’environnement :

environment {
  XDG_CACHE_HOME='/tmp/.cache'
  GOOS='linux'
  GOARCH='amd64'
}

XDG_CACHE_HOME permet de spécifier le répertoire où les données mises en cache vont être écrites. Ce répertoire est utilisé lors de la résolution des modules Go. Si on ne le spécifie pas le user du container n’a pas les droit d’écriture et cela perturbe le build.

GOOS permet de spécifier le système d’exploitation cible pour la compilation. Ici nous choisissons “linux” car c’est la valeur nécessaire pour AWS Lambda.

GOARCH permet de spécifier l’architecture cible (en gros le type de processeur) pour la compilation. De même nous choisissons la valeur nécessaire pour AWS Lambda.

Enfin le reste du code permet de récupérer le projet à partir de GitHub, créer un lien symbolique dans le répertoire GOPATH et pour finir de compiler le projet.

Deuxième étape : les tests unitaires

L’étape suivante de notre pipeline sera de lancer les tests unitaires et d’afficher un rapport des résultats obtenus. En effet pour l’instant la seule chose dont on est sûr c’est que notre code compile, cela ne veut dire qu’il fait ce qu’il est sensé faire !

Nous allons donc rajouter une étape dans notre Jenkinsfile :

Une fois la configuration du pipeline mise à jour et après une nouvelle construction de ce dernier vous devriez voir ceci :

Concernant les instructions de cette étape, elles consistent à installer un outil qui s’appele “go-junit-report” dans un premier temps. Cet outil permet de formater les résultats des tests Go en utilisant le format Junit, ce qui nous permet par la suite d’utiliser le plugin Jenkins associé pour afficher le rapport de tests.

Ensuite on lance les tests Go en redirigeant la sortie vers l’outil “go-junit-report” qui à son tour écrira le résultat dans le fichier “report.xml”.

Enfin on a une étape qui permet d’afficher le rapport de tests après l’exécution de l’étape en utilisant le plugin “JUnitResultArchiver”.

Il peut-être intéressant de vérifier le bon fonctionnement de ces instructions dans le cas où un test échoue. Pour cela il est possible de modifier un test à la volée pour le faire échouer sciemment. Nous utiliserons alors la commande “sed” qui est un éditeur de stream, en remplaçant “???” par “N/A” :

sh "sed -i -e 's|???|N/A|g' categorizer/categorizer.go"

Si nous relançons le pipeline nous constatons que le test échoue et que le rapport permet de constater cet échec et d’en afficher les détails :

Troisième étape : le linting

Qu’est-ce que le linting ? Le linting est la vérification automatisée de votre code source pour détecter des erreurs de programmation et de style. Le linting est important pour améliorer la qualité globale de votre code. A long terme cela peut vous aider à développer plus vite et à réduire les coûts en trouvant les erreurs plus tôt.

L’écosystème Go propose deux outils de ce type : GoLint et GoVet. Le premier s’attarde principalement sur le style du code source tandis que le second signale les constructions suspectes, telles qu’un Printf dont les arguments ne correspondent pas à la string de formattage.

Rajoutons un étape supplémentaire à notre pipeline :

Il vous faudra également installer le plugin Warnings Next Generation, en allant dans le menu “Administrer Jenkins”, puis dans “Gestion des Plugins”.

Une fois le plugin installé, la configuration du pipeline mise à jour et après une nouvelle construction de ce dernier vous devriez voir ceci :

Comme pour les tests unitaires il est possible de modifier les fichiers à la volée afin de s’assurer que les instructions de cette étape font le job :

sh "sed -i -e 's|NewBroker will|this will|g' messaging/message.go"

sh "sed -i -e 's|objectKey, bucket|objectKey, 1337|g' config/config.go"

Si nous relançons le pipeline nous constatons que des avertissements sont détectés et que le rapport permet d’en afficher les détails :

Améliorations possibles

Le pipeline fonctionne parfaitement en l’état, il y a toutefois quelques détails qui me chagrinent.

Tout d’abord il y a la répétition des commandes :

cd $GOPATH/src/github/jbleduigou/budgetcategorizer &&

Ces commandes alourdissent le code à mon avis. Cela rend plus difficile la compréhension du pipeline à la première lecture. J’ai essayé de rajouter une variable d’environnement GOPATH afin de pouvoir utiliser la syntaxe :

dir("GOPATH") {
 [...]
}

Malheureusement je n’ai pas réussi à ce que cela fonctionne donc pour l’instant je reste avec la syntaxe de changement de répertoire.

Autre chose, j’ai voulu zipper le binaire obtenu en sortie de compilation. Malheureusement la commande zip n’est pas présente dans l’image Docker officielle de Golang. Je pourrais construire ma proche image Docker pour cela mais je trouve que c’est beaucoup de travail pour un détail pas si important.

J’espère que cet article vous a plu !
Le code de la lambda utilisée pour cet article est sur GitHub : https://github.com/jbleduigou/budgetcategorizer
Le pipeline Jenkins complet se trouve dans le répertoire “ci” : https://github.com/jbleduigou/budgetcategorizer/blob/master/ci/Jenkinsfile.groovy
N’hésitez pas à me faire part de vos commentaires ou questions en bas de cet article ou en m’envoyant un message sur LinkedIn :
http://www.linkedin.com/in/jbleduigou/en