Evolution de la méthode de développement de Jeedom

Bonjour,

Comme certains l’ont surement constaté et suite au gros sujet « Où va Jeedom » du Community, nous avons depuis quelques mois fait évoluer la manière dont Jeedom est développé. Je vais dans cet article essayé de vous exposer les nouvelles méthodes :

• Mise en place de validation pour les changements venu de personnes externes a la societé (ce qu’on appels des PR), il faut maintenant que deux personnes de Jeedom valide la modification pour que cela soit intégré. Cela nous permet de mieux contrôler les changements, d’avoir une double validation et surtout d’être plus fluide sur l’acceptation de ces changements.

• Idem pour le passage en beta ou stable : il faut aussi une double validation (même triple car seul quelqu’un de Jeedom peut faire la demande pour une beta ou stable et cette personne ne peut bien évidement pas se valider elle même)
• Passage en mode « issue » pour tout ce qui est bug ou évolution, vous pouvez les retrouver ici : Issues · jeedom/core (github.com), tout est public vous pouvez donc maintenant suivre ce qui est prévu comme évolution et voir où cela en est. Idem pour les bugs, tout est déclaré en issue et vous pouvez suivre l’avancement de la correction. A noter que certaines évolutions (issues) sont marquées de la version cible, cela vous permet d’avoir une idée de la roadmap

• Les changelogs sont aussi maintenant beaucoup plus précis avec à chaque fois un lien vers l’issue ou le PR (ca permet de tracer exactement toute les modifications)

• Passage de tous les plugins sur des repositories github public, vous pouvez donc maintenant voir le code de tous les plugins et proposer des améliorations
• Chaque nouvelle version du core créé un tag : cela permet si besoin de revenir au code de la version en question

A venir

Et ce n’est pas fini voila ce que nous prévoyons pour l’avenir :

• Refonte des branches, l’idée serait d’avoir plus que beta/master (ou dev/stable ou un truc du genre)
• Application des évolutions du core sur les plugins (c’est lourd, clairement les changements de méthodologie sur le core nous prenne pas mal de temps donc nous allons chercher à optimiser un maximum avant de le déployer partout)
• Passage du développement du core sur des cycle (de X mois), c’était prévu en avril mais pour le moment nous nous concentrons surtout sur la correction des bugs et cela à malheureusement retarder notre planning
• Réflexion sur la mise en place d’un changelog automatique en fonction des commits (pas évident, surtout la partie gestion de la langue)

Autre changement

Nous avons aussi eu quelques changements en interne avec le départ d’Alexandre ಥ_ಥ et l’arrivée en mode pompier de Johan.

Il a mis en place le principe de task force pour résoudre les problèmes urgents (type la partie 4g des Luna en ce moment). Cela nous permet d’être plus flexible et réactif sur les soucis.

Voila, en espérant que cet article vous aide a mieux voir « où va Jeedom » et surtout vous montrer le tournant majeur que cela a été pour nous (et c’est pas fini).