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é!
Trouver les idées
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.
Étudier le besoin
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é.
- Si la fonctionnalité remplit ces deux critères, la carte est déplacée dans la colonne “Traité” et une User Story est ajoutée au Product Backlog dans Jira.
- Sinon la carte est déplacée dans la colonne “Won’t Do”.
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!
Prioriser les tâches
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”.
Développer la fonctionnalité
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.
Création d’une branche pour la fonctionnalité
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
Test Driven Development
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”.
Écriture du code et des tests unitaires
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.
Écriture de la documentation
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.
Pull Request avec intégration et déploiement continu
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:
- Build et déploiement de la documentation sur Netlify
- Analyse de la qualité du code avec ESlint, SonarQube et LGTM
- Tests unitaires et mesure de la couverture du code avec Mocha et Codecov
- Tests fonctionnels avec Cucumber
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.
Déploiement en préproduction
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:
- Build et push d’images sur Dockerhub (kuzzleio/kuzzle:2-dev et kuzzleio/plugin-dev:2-dev)
- Déploiement de la documentation sur https://next-docs.kuzzle.io/
Livrer la nouvelle version
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:
- Génération du changelog de la nouvelle version
- Création d’une pull request de la branche de développement vers la branche stable
- Création d’un tag avec la nouvelle version et la release Github associée
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.
Ce qui change avec l'Open Source
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.
