Comme vous le savez, Kuzzle est un produit open source dont la totalité du code est consultable librement sur Github.
Pour continuer dans cette démarche d’ouverture, nous avons décidé de rendre nos méthodes de travail “open source” afin que chacun puisse comprendre les processus que nous utilisons tous les jours pour faire avancer nos projets.
Nous suivrons tout au long de cet article les étapes du développement d’une véritable fonctionnalité!
Les idées ce n’est pas ça qui manque. Afin de ne pas surcharger Kuzzle de fonctionnalités peu ou pas utilisées, chaque idée doit être accompagnée d’un cas d'usage concret.
Chacun est libre de proposer une fonctionnalité, que ce soit un membre de l’équipe, un client ou la communauté.
Tout commence par une demande d’un de nos client sur Slack.
Toutes ces idées sont ensuite ajoutées dans le backlog de notre Atelier Produit.
Une fois toutes les deux semaines, l’équipe se réunit pour débattre pendant 1 heure des idées soumises à l’atelier produit.
Nous utilisons Trello pour lister les idées ainsi qu’un script pour tirer au hasard une carte.
Proposition de la fonctionnalité dans notre atelier produit.
La personne ayant soumis l’idée doit ensuite expliquer le fonctionnement potentiel de la fonctionnalité ainsi que le cas d'usage lié à cette dernière.
Le but de l’atelier est de s’assurer de deux choses : Utilité et Faisabilité.
Une fonctionnalité refusée à cause de sa non-faisabilité en environnement cluster.
L’archivage est important afin de garder une trace des fonctionnalités ayant été approuvées ou non!
La troisième étape de la vie d’une fonctionnalité est sa priorisation lors du Backlog Refinement.
Toutes les deux semaines, nous analysons notre tableau Kanban dans Jira pour prioriser les tâches à réaliser dans les deux semaines à venir.
Vue du Product Backlog. Sur la droite, la tâche acceptée depuis l’Atelier Produit
Cette priorisation est réalisée de façon collégiale, en concertation avec l’ensemble de l’équipe.
Nous prenons en compte les besoins de nos clients mais aussi ceux de la communauté grâce à notre roadmap publique.
Les tâches ainsi priorisées sont déplacées dans la colonne “To do”.
Une fois qu’une tâche a été priorisée dans la colonne “To Do”, chacun est libre de se l’attribuer pour la réaliser.
Cela fait partie de notre mode d’auto-gestion de l’équipe, où chacun organise son travail comme il le souhaite, en fonction des besoins autour du produit.
Nous utilisons Gitflow pour l’ensemble de nos développements, ce qui signifie que chaque fonctionnalité est réalisée sur une nouvelle branche créée à partir de la branche courante de développement.
Architecture d’un dépôt Git avec Gitflow
La première étape est d’écrire les tests fonctionnels en utilisant la syntaxe Gherkin de Cucumber.
Ainsi il sera possible de tester le fonctionnement du code lors de la phase de développement sans devoir réaliser les actions à la main ou via un script “jetable”.
Ensuite, c’est l’écriture du code de la fonctionnalité à proprement parler.
Une attention particulière doit être portée lors du traitement des entrées de l’utilisateur pour prévenir les failles de sécurité et également lors de la modification de zones critiques de code qui peuvent être potentiellement exécutées plusieurs centaines de fois par seconde.
Finalement, les tests unitaires doivent être écrits pour assurer une maintenabilité future maximale.
La documentation de chaque projet se trouve à l’intérieur du dépôt et doit donc être mise à jour en même temps que l’ajout de la fonctionnalité.
Si la nouvelle documentation inclut des exemples de code, ceux-ci devront également être testés avec notre framework de test de documentation.
En plus de la facilité de relecture d’une pull request incluant le code et la documentation, cela nous permet d’être assuré que le déploiement d’une fonctionnalité est toujours accompagné de la documentation associée.
Une fois tout le travail nécessaire réalisé, une pull request est créée.
Pull Request de la fonctionnalité sur le dépôt Kuzzle.
Celle-ci doit respecter le format standard afin de faciliter sa relecture par les membres de l’équipe.
Chaque pull request doit être approuvée par 3 membres de l’équipe afin de s’assurer de la meilleure qualité possible du nouveau code produit.
Finalement, chaque étape de notre CI doit être validée pour que la pull request puisse être définitivement validée.
Notre CI fonctionne avec Travis et inclut les étapes suivantes pour les pull requests:
Une fois que la CI est passée et que l’équipe a approuvé, la pull request est fusionnée dans la branche de développement avec un squash merge, avec pour description un résumé de la fonctionnalité, servant d'historique dans Git.
Les fonctionnalités livrées sur la branche de développement sont ensuite déployées en préproduction.
Ce déploiement automatique inclut les étapes suivantes:
Régulièrement, nous préparons la livraison d’une nouvelle version incluant les dernières fonctionnalités développées.
Pour cela, nous utilisons un outil interne qui va automatiquement réaliser les différentes étapes:
Changelog de la release incluant la fonctionnalité.
Ensuite, comme lors du déploiement en pré-production, notre CI va s’occuper de déployer les images de production sur Dockerhub ainsi que la documentation et les packages NPM.
Vous pouvez vous dire que ces étapes sont les étapes standards du cycle de vie de développement d'une fonctionnalité et vous avez raison!
Ce qui change avec l'Open Source c'est surtout la manière de réaliser ces étapes en impliquant la communauté dans chacune d'entre elle.
Ainsi chacun peut par exemple proposer une fonctionnalité sur Github ou venir nous parler sur Discord.
Vous pouvez ensuite nous aider à prioriser les fonctionnalités en votant sur notre roadmap publique.
Finalement, chacun est libre de venir contribuer ou auditer les phases de développement car tout est publique sur Github.