La stack d’outils collaboratifs parfaite ?

Bien développer, c’est d’abord bien s’organiser, seul ou en équipe.

Et bien s’organiser, ça passe par des process, qui eux-mêmes nécessitent des outils. C’est de ces derniers qu’on va parler en priorité aujourd’hui.

Récemment, j‘ai souhaité mettre en place un ensemble d’outils collaboratifs qui permettraient à une petite équipe de dév (5+ personnes), de travailler de manière agile sur un projet, dans les meilleures conditions possibles.

Est-ce que c’est vraiment important ?

Après tout, quand on démarre un projet, c’est pas le genre de décision qui a l’air hyper stratégique… Néanmoins, au quotidien, ils sont là avec nous, 8 heures par jour, on n’a donc plutôt interêt à bien les choisir puis apprendre à en tirer le maximum.

J’ai remarqué que prendre le temps de choisir de bons outils (et process donc) en fait gagner énormément, et ce, même à court terme et même en étant seul.

Ensuite, lorsqu’on développe 8 heures par jour, on a tout interêt à ce que notre environnement soit le meilleur possible, pour ne pas être agacé ou retardé par des choses futiles qui pourraient être évitées facilement. Plus les process sont fluides, les outils fonctionnels et simples, plus on conserve notre énergie pour affronter ensuite les vrais problèmes. De la même manière qu’on souhaite avoir un environnement de travail agréable avec un ordinateur suffisamment rapide, une chaise confortable et un bon éclairage, il est nécessaire d’avoir des outils software qui permettent de faciliter la vie de l’équipe au quotidien en assurant une bonne communication, la centralisation de la documentation, un code homogène et de qualité, des mises en prod réussies, etc…

De plus, ces outils étant devenus gratuits ou largement abordables, et rapides à mettre en oeuvre, il n’y plus vraiment d’excuse à ne pas s’en servir, si ce n’est de ne pas les connaitre…

Mes critères pour le choix des outils étaient les suivants :

Rapides à mettre en oeuvre : pas de grosse config lourde, privilégier les outils SaaS
Largement répandus en start-up (exit les solutions exotiques que personne ne connait et ne voudra utiliser)
Qui s’intègrent les uns aux autres, par exemple avec des webhooks (on verra après pourquoi c’est très utile)
Dont le périmètre couvre l’ensemble des besoins d’une petite équipe de dév pour un projet web classique (type start-up)
Avec une vraie valeur ajoutée. Trop d’outils peuvent créer une certaine fatigue, et l’ajout d’un outil dans la stack doit avoir un apport indiscutable, sinon il n’a pas sa place.

Bien sûr, cette liste est non-exhaustive, complètement subjective, et adaptable en fonction des besoins spécifiques du projet. Bon nombre d’outils sont remplaçables par d’autres couvrant à peu près le même spectre de fonctionnalités.

Trello

Trello est un outil SaaS de gestion de projets en mode Kanban (très à la mode). Typiquement j‘aime quand un projet est plus ou moins découpé avec ces différentes colonnes :

Backlog P+ : les tâches non prioritaires (à intégrer dans un sprint futur)
Backlog P0 : les tâches du sprint courant.
In progress : les tâches en cours.
Wait : les tâches en cours mais qui ne peuvent avancer indépendamment de notre volonté (parce qu’elle nécessitent un retour par ex.)
Done : les tâches terminées (on garde l’historique car c’est toujours utile de savoir ce qui a été fait dernièrement, notamment pour la motivation).

Au niveau du contenu, en général on y met des user-stories, et on peut y ajouter des tâches diverses, technique ou pas, mais qui ne sont pas directement liées au code lui-même (car on lui préférera GitHub pour ça). Tout dépend de vos process en fait.

Trello a l’avantage d’être simplissime à utiliser mais suffisamment générique pour s’adapter à plus ou moins n’importe quelle méthodologie de travail pas trop spécifique.

Certains préfereront utiliser un vrai tableau avec des Post-it car c’est encore plus visuel. Pourquoi pas, mais pour votre collaborateur qui travaille en remote aujourd’hui, c’est cuit :)

Github

C’est la plate-forme SaaS indispensable qui aura plusieurs rôles distincts :

Héberger, sécuriser et versionner le code
Gérer les “issues” : ouvrir et fermer différents tickets qui contiendront des tâches directement liées au code, que ce soit des features, des bugs, ou autre.
Gérer les pull requests : si on choisit d’utiliser le système de branche de Git, alors les pull requests Github permettent de faciliter la validation du code pour le merger dans une branche principale. La validation d’une PR permet de fermer automatiquement une issue Github.
Gérer un wiki directement lié à la codebase. Plutôt que de disséminer des documents partout, qui à la fin ne sont lus par personne, le wiki Github permet de centraliser la documentation du projet en mettant un accent sur la lisibilité. Un projet documenté n’est pas du luxe, ça devrait être une tâche continue (qui pourrait d’ailleurs faire l’objet d’un article à elle-seule). Non, la documentation ne peut malheureusement pas être entièrement dans le code. Non, la documentation ne peut pas se résumer à des transmissions orales ou à des mails. Si, il faut quand même documenter si on est seul, car notre mémoire n’est pas infaillible, et car on ne reste pas forcément seul.

Travis CI

Travis CI est un outil d’intégration continue en mode SaaS permettant de nous assurer que le code pushé passe toujours un ensemble de tests. Il permet donc de nous assurer de la non-régression dans notre codebase à chaque push/merge.

Travis CI est complètement intégré à Github. Par exemple, une pull-request avant même d’être acceptée, pourra déclencher Travis automatiquement pour vérifier que le code, s’il est mergé, fonctionne toujours parfaitement.

On pourrait croire que ce n’est pas indispensable, néanmoins il est possible d’oublier de lancer les tests sur son environnement local avant de pusher (ce qui n’est pas possible sur le CI). De plus, le fait de lancer les tests sur un environnement complètement séparé est une garantie supplémentaire.

Codestyle checker

A qui ça n’est jamais arrivé ? Vous pullez du code, et tout à coup, le linter de votre IDE devient fou devant tant de warnings. Vous corrigez cela sur le fichier en cours mais il y en a plein d’autres touchés par ce mal ! Vous finissez par insulter votre collègue (dans votre tête si vous êtes poli). Empêcher cette situation de se produire est pourtant simplissime :

On se met d’accord sur une norme par langage, et on en démorde pas. En Python c’est facile il y a la PEP8 et rien d’autre. En Javascript il y a par exemple Eslint. Il peut y avoir quelques discussions sur des exceptions à configurer (par exemple : accepter 100 colonnes au lieu de 79 en Python).
Chaque développeur installe le même outil de validation du code (en Python il y a Flake8 par exemple).
Chaque développeur créé un git-hook de pré-commit qui l’empêchera de commit du code qui ne respecte pas la norme. C’est radical, mais il est tellement facile de dire “je le ferai plus tard” s’il n’y a pas ça…
Encore mieux, on empêche le build si jamais la norme n’est pas respectée. Ainsi, même si un dév oubli de configurer la validation sur son environnement local, la dure réalité du build failed lui sera rappelé.

Au final, à tout instant, la codebase respecte une unique norme. Elle est complètement homogène, et chaque collègue peut comprendre et travailler facilement sur le code des autres. Plus personne ne s’énerve, la vie est belle.

Heroku

Je suis limite hors sujet car Heroku est un hébergeur web de type PaaS, et pas un simple outil. Mais alors pourquoi j’en parle ici ?

Parce qu’une plate-forme comme Heroku, en plus de faciliter l’hébergement, propose un ensemble d’outils qui simplifient énormément la vie pour démarrer un projet web.

Sans trop rentrer dans le détail (car là aussi ça pourrait être un article à part entière), voilà ce qu’on va pouvoir en tirer :

Pas de configuration au niveau OS et serveur (c’est le concept du PaaS)
Une gestion des environnements ultra simplifiée avec Heroku Pipeline : concrètement, vous passez votre app de l’environnement de staging vers la prod en 1 clic (ou 1 commande) et en 1 seconde. Magique…
L’intégration avec Github (un push sur une branche qui déclenche le build sur Travis puis sur l’app Heroku) Backup journalier automatique de la base de données, providing du certificat HTTPS, mode maintenance, protection anti-ddos. Beaucoup d’autres…

Sentry

Faisons un constat simple. Malgré vos tests unitaires et tout le soin apporté à votre projet, vos clients auront des erreurs en prod, et c’est normal.

Mais dans ces cas là, il est indispensable :

d’être mis au courant le plus rapidement possible.
de pouvoir comprendre le plus rapidement d’où vient l’erreur pour pouvoir prendre les mesures nécessaires dès que possible.

Sentry répond exactement à cette problématique en proposant un dashboard d’événements qui va permettre d’afficher les erreurs de la plus lisible des manières, en collectant un maximum d’informations liées. On est très loin du vieux traceback de 1000 lignes illisible.

Vous serez alertés en temps réel par mail, Slack, ou même SMS. Indispensable dès la première mise en prod pour dormir sur ses deux oreilles.

Slack

Tous les outils ci-dessus sont extremement pratiques. Ce qui l’est moins, c’est de devoir ouvrir 10 onglets internet en même temps pour suivre ce qui s’y passe…

Slack, en plus de la partie discussions, va permettre de centraliser l’activité sur ces outils à 1 unique endroit grâce à l’utilisation d’apps. Après une simple configuration, on pourra par exemple retrouver dans des channels distincts :

Les commit, activités sur les issues et PR de Github
Les activités sur les tâches Trello
Les alertes Sentry (très important)
Le résultat des build sur Travis CI et sur Heroku

A la fin, l’équipe de dév à une vision globale du projet à tout instant, juste ave Slack. Très pratique !

2 mises en garde par rapport à ça :

Attention à ne pas être trop déconcentré à vouloir lire toutes les notifications dès qu’elles apparaissent.
Trop d’infos tue l’info ! Il faut absolument limiter les messages Slack à ce qui est utile/intéressant, sinon plus personne n’y fera attention au final, ce qui deviendrait contre-productif.

Vagrant

Rien de plus énervant qu’un test unitaire qui passe chez un collègue et pas chez vous, avec la même codebase. En général, c’est parce que vos environnements sont différents. L’un a Ubuntu 14 avec Python 2.7.6, l’autre Ubuntu 16 avec Python 2.7.13. Le plus fourbe c’est que la plupart du temps, ça ne pose aucun problème. Mais la règle est simple : un environnement local le plus iso-prod et le plus “iso-collégue” possible vous évitera beaucoup de soucis.

Vagrant a pour slogan : “Development Environments Made Easy”.

Pour illustrer ça, imaginons ce scénario : 2 nouveaux développeurs rejoingnent aujourd’hui votre équipe, l’un sous mac OS, l’autre sous Ubuntu. Comment faire pour qu’ils installent un environnement de dév local strictement identique, et ce, très simplement ?

Avec Vagrant installé, ces développeurs ont juste à récupérer votre fichier de config de projet Vagrant de quelques Ko (celui qui stipule de quelle manière créer et configurer la VM) et lancer 1 ligne de commande : vagrant up.

Ils n’ont plus qu’à attendre quelques minutes que l’OS soit téléchargé, la VM installée, les packages téléchargées. A la fin du process, ils ont chacun la même VM, et sont prêts à travailler. Pratique non ?

A noter que Vagrant automatise la création d’un dossier partagé/synchronisé entre l’OS hôte et la VM pour que les développeurs puissent utiliser leur IDE sur leur système hôte, tout en modifiant les fichiers sur la VM. Dans les faits, ça marche.

Note : je ne connais pas bien Docker mais il me semble que ce soit possible de répondre à des besoins similaires avec.

Conclusion

De prime abord, l’ensemble de ces outils, s’ils n’ont jamais été utilisés, peuvent sembler intimidants et il pourrait être tentant de se dire “je le ferai plus tard quand j’en aurai vraiment besoin”. Mais la mise en place et l’utilisation sont beaucoup plus simples et rapides qu’elles n’y parraissent. Après ça, le retour en arrière est impossible tellement ces outils vous aident dans votre organisation personnelle et collective.

Certains outils comme le “codestyle-checker” sont beaucoup plus compliqués à mettre en place lorsque la codebase fait déjà 100 000 lignes. C’est pourquoi je recommande de s’y atteler le plus tôt possible dans le cycle de développement, et d’impliquer l’ensemble des développeurs dans leur utilisation et leur évolution.

Pour finir, les outils ne se substitueront jamais à des bons process et des bons développeurs, mais bien utilisés, ils pourront drastiquement augmenter la productivité et le bien-être de ces derniers, en conservant leur énergie pour affronter les vrais problèmes !