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.
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 :
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 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 :
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 :)
C’est la plate-forme SaaS indispensable qui aura plusieurs rôles distincts :
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.
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 :
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.
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 :
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 :
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.
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 :
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 :
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.
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 !