Partage de configurations frontend entre nos équipes chez Ornikar

Introduction

Lorsque j’ai rejoint Ornikar en 2018, il n’y avait qu’une seule équipe de développeurs mais déjà plusieurs dépots git séparés, incluant un pour la webapp de nos clients et un pour notre design system.

Désormais, nous avons plus d’une dizaine d’équipes de développeurs différentes et de nombreux projets. Mais nous partageons la plupart de nos configurations et recommandations, et 4 groupes transverses se réunissent tous les mois pour travailler sur des bonnes pratiques et sur nos dépendances. Toutes les équipes front prennent le temps de communiquer et challenger leurs problématiques respectives, tout en conservant leurs productivités. Je pense que l’une des raisons est ce partage de configurations.

Partage de bonnes pratiques

La plupart de nos bonnes pratiques sont imposées par eslint. Eslint est un super outil car il est automatisé, fait échouer la CI et intégré dans nos IDEs qui corrige automatiquement le code à la volée lorsque c’est possible.

Des développeurs ne devraient pas passer du temps à faire appliquer une bonne pratique dans les pulls requests lues, quand c’est possible de l’automatiser. Un bon exemple pour illustrer:

Exemple d’un commentaire pour une bonne pratique dans une PR qui devrait etre automatisé avec eslint.

Nous avons aussi une documentation de bonnes pratiques hébergée sur Confluence, nous nous en servons comme un recueil d’explications de certaines règles eslint. Pourquoi cette règle est une bonne pratique ? Comment corriger l’erreur ? Ainsi que des exemples de quelques cas.

Exemple de documentation pour éviter l’export default

Nous utilisons la configuration eslint d’airbnb qui contient un bon nombre de bonnes pratiques. Airbnb a développé un guide de bonnes pratiques pour ses équipes qui décrit les règles pour les espaces, conventions de nommage, etc. En plus de cette configuration, nous avons ajouté typescript-eslint pour des bonnes pratiques spécifiques à Typescript, unicorn qui ajoute également de nombreuses bonnes pratiques, et quelques autres.

Ces configurations eslint sont situées dans notre dépot git public eslint-configs et publiés sur npm. Ces packages sont installés en dev dependency de toutes nos applications frontend.

Ajouts de bonnes pratiques

Chaque équipe frontend a un référent pour les bonnes pratiques. Ces membres se retrouvent mensuellement lors d’une réunion pour améliorer nos configurations eslint partagées, pour ajouter ou modifier des règles, discuter des problèmes auxquels les équipes ont été confrontées le mois durant en apportant des pistes d’amélioration. Nous créons des tâches et les nous nous les répartissons pour le meeting suivant, afin de faire évoluer nos applications de façon continue.

Tous les projets n’ont pas la même maturité. Nous testons parfois une règle sur un projet pour valider son usage avant de l’appliquer sur la configuration partagée. Il arrive aussi de désactiver une règle sur un projet car elle ne correspond pas aux besoins. Toutes les règles ne nécessitent pas d’être partagées universellement, c’est pourquoi le pilotage de ces règles en comité et leurs tests préliminaires sur un échantillon de nos applications nous permettent de trouver le bon équilibre entre des pratiques partagées que chaque développeur adopte, et une flexibilité adaptée à chaque projet.

Récemment, nous avons également mis en place un planning de release pour avoir le temps de mettre à jour les configurations partagées sur chaque application:

Planning de release pour sur 1 mois

Avant ce planning, les règles étaient ajoutées ou changées puis publiées plusieurs fois par mois, ce qui rendait difficile la mise à jour des applications. Nous publions maintenant une seule fois par mois et laissons 2 semaines à l’équipe pour mettre à jour cette configuration.

Mises à jour automatisées

Pour nous aider à mettre à jour nos configurations partagées, nous utilisons Renovate, un bot github qui ouvre des Pull Requests pour mettre à jour nos dépendances. Nos configurations partagées sont mergées automatiquement si aucune action humaine est requise. De cette façon, on ne perd pas de temps à relire des PRs de config si ce n’est pas nécessaire !

Nous partageons également la configuration de renovate et chaque projet frontend l’utilise.

Mise à jour de @ornikar/eslint-config dans shared-configs

Configuration basique de projet

Tous les projets frontend utilisent également le package @ornikar/repo-config. Il contient la configuration pour :

• Husky, pour les hooks git
• Lint-staged, pour lancer des linters sur les fichiers source lors du commit
• Commitlint, pour respecter conventional commit pour le message de chaque commit

Nous avons également une variation pour nos projets react, @ornikar/repo-config-react. Celle-ci ajoute :

• Svgo, pour minifier les svgs lors du commit (et non au build ce qui coute du temps à chaque build)
• Typed-css-modules, pour génerer .d.ts pour les fichiers css modules.

De plus, nous avons quelques packages pour des configurations de librairies:

• pour browserslist : @ornikar/browserslist-config
• pour commitlint : @ornikar/commitlint-config
• pour prettier : @ornikar/prettier-config

Autres configurations partagées

Mais ce n’est pas tout ! Nous partageons aussi des configurations pour jest, rollup (pour nos monorepo), storybook ou webpack. Nous partageons aussi des configurations circleci via des orbs et avons une extension vscode.

À quoi ressemble un projet

Pour vous donner une idée de ce à quoi ressemble un projet avec nos configurations partagées, n’hésitez pas à jeter un coup d’œil à notre dépôt open-source eslint-configs.

package.json dans eslint-configs

Conclusion

Partager nos configurations nous offre de nombreux avantages, comme la communication inter-équipes, ainsi que le partage de nos connaissances et de nos bonnes pratiques. Cela signifie que tout le frontend d’Ornikar parle le même langage et a la même façon d’écrire du code, ce qui permet des review de code plus facile. Ces ponts facilitent la réutilisation de code d’un projet à l’autre lorsqu’une implémentation a déjà été réalisée dans une autre équipe…

Nous l’avons constaté dans beaucoup de cas ces derniers mois, comme réutiliser un outil externe ou mettre à jour une librairie avec des changements importants. C’est du temps gagné par les équipes pour le développement d’autres fonctionnalités, et également par ceux qui maintiennent ces règles, car elles sont centralisées !

Cependant, je vois des inconvénients à cette approche. Premièrement, on doit s’assurer que les changements faits sur les configurations partagées fonctionnent partout. Parfois les développeurs ne sont pas à l’aise pour changer une configuration qui va impacter d’autres projets puisqu’ils ne savent pas exactement comment ils fonctionnent. En pratique, ça ne pose pas de problème de faire des erreurs tant qu’il y a de la communication. La plupart de nos configurations sont testées via la CI donc si celle-ci échoue, Github va nous empêcher de merger et n’impacte pas immédiatement les équipes travaillant sur ce projet, mais requiert tout de même vérification et correction. Le second inconvénient que je vois est que la communication peut prendre du temps. Les équipes peuvent néanmoins essayer de nouvelles configurations dans leur application avant de les appliquer aux configurations partagées.

Nous partageons également des composants react et un design system, mais c’est une histoire pour un autre billet de blog ! N’hésitez pas à partager des idées ou retours d’expérience que vous avez en commentaire, j’ai hâte de vous lire 🙂