fabernovel loader

7 juil. 2017 | 3 min de lecture

Tech

Angular, Drupal, Symfony... : le rythme apaisant du versioning cadencé

Julien Mession

Head of Innovation


FABERNOVEL CODE
Ne dites plus Angular2, Symfony3, Bootstrap4... Mais Angular, Symfony, Bootstrap !

Pour les projets Open Source comme pour les autres, la notion de time-to-market est cruciale. La fiabilité et la régularité des releases sont au moins aussi importantes que la puissance fonctionnelle.

Petit coup d’oeil dans le rétroviseur : fin 2013, la communauté Drupal est en ébullition. Après 3 années d’intense labeur et une refonte intégrale, la sortie de la version 8 tant attendue est imminente. Tous les meet-ups PHP se font l’écho des progrès apportés par cette version, les intégrateurs en ont l’eau à la bouche et sont prêts à en découdre. Et puis… Et puis rien jusque fin 2015. L’énorme ambition du projet (3000 contributeurs, 15000 commits), l’exigence des contributeurs et le pilotage non-agile du développement par ses gourous demanderont 2 ans de plus pour sa sortie officielle (non je ne parle pas des déboires de l’A400M). De nombreux développeurs découvrent alors sa complexité et les difficultés à intégrer un écosystème de modules en majorité immatures. Beaucoup sont définitivement rebutés. Car en 5 ans, les cartes ont été rebattues : WordPress (quoi qu’on en pense) a encore gagné du terrain y compris dans les entreprises, les frameworks Symfony ou Laravel ont séduit un large public, et d’autres stacks, JavaScript notamment, ont conquis le coeurs des jeunes développeurs.

J’aborde ici la difficile gestation de Drupal8, mais beaucoup d’autres projets ont connu ces longs tunnels de développement, avec parfois à la sortie un cruel décalage entre les attentes et la réalité (PHP6, ouille !).

Pour améliorer cet état de fait, les développeurs ont cherché à raccourcir et à stabiliser le rythme des releases.

Citations :

  • WordPress : « Après la version 2.1, nous avons décidé d’adopter un calendrier de diffusion régulier tous les 3-4 mois avec les fonctionnalités principalement motivées par des idées votées par nos utilisateurs« .
  • Symfony : « Symfony gère ses versions grâce à un modèle basé sur le temps. Une nouvelle version mineure de Symfony se produit tous les six mois, une en mai et une en novembre ».
  • Angular : « Nous mettons en œuvre des versions sémantiques et de nouveaux processus de développement afin de garantir que les changements futurs soient toujours introduits de façon prévisible ».
  • Bootstrap : « Pour de la transparence dans notre cycle de changement de versions et tout en s’efforçant de garder une compatibilité ascendante, Bootstrap est maintenu sous les directives de la Version sémantique. Parfois, nous échouons, mais nous essayons de respecter ces règles dès que possible ».

Le versioning sémantique (type X.Y.Z) est devenu le standard de cette cadence. Rien de très nouveau dans les faits, plutôt une généralisation qui, couplé à une cadence de livraison élevée, a un profond impact, au point que le numéro de version a disparu de la plupart des dénominations, alors qu’avant c’était un argument marketing. Parallèlement, la cadence élevée de livraisons a enlevé une grosse partie du stress lié au passage de version « ancienne mode ».

Quel enfer de passer de Symfony1 ou d’Angular1 à la version 2 ! D’ailleurs beaucoup de projets n’ont pas eu les moyens de le faire. Par contre, personne ne parle du passage d’Angular 2 à 4 (pas de 3, oui, ça arrive) ou de Symfony 2 à 3. C’était déjà le cas pour les navigateurs : on se souvient avoir prononcé le 3 de Firefox3 (de 2008 à 2012 !), mais maintenant qu’un incrément de produit est livré chaque mois, on dit simplement Firefox ou Chrome.

Que s’est-il passé ? Les APIs sont-elles enfin stabilisées pour l’éternité ? Les nouvelles architectures logicielles résistent-elles à tous les assauts fonctionnels ?

Evidemment non, il n’y a pas de miracle du versioning sémantique. Simplement, le raccourcissement des itérations a changé la manière d’aborder le cycle de vie des fonctionnalités en évitant les dérives et les effets tunnels :

  • Fonctionnellement les solutions collent plus pragmatiquement aux besoins car le feedback est rapide. Certains produits proposent même à leurs communautés de voter pour prioriser le backlog.
  • Les builds sont plus stables : les descripteurs composer, npm & co peuvent cibler précisément les versions utilisées à instant T, et dans 2 ans on pourra toujours lancer un build sans craindre de faire remonter des versions incompatibles.
  • La montée en version est plus sécurisée car le code évolue progressivement, en communiquant sur les dépréciations à venir. Il n’y a plus de rupture brutale comme auparavant.

 

Cette logique s’est imposée et fonctionne évidemment avec tous les types de projets. En particulier ceux de nos clients pour qui la notion de time-to-market est cruciale et qui ont besoin d’une stratégie maîtrisée de déploiement régulier d’incréments de produit. Nous avons constaté un net gain en stabilité et en transparence depuis qu’on applique ce standard à chaque incrément de produit sorti d’un sprint scrum.

Cet article vous a plu ?

Contactez FABERNOVEL CODE
logo business unit

FABERNOVEL CODE

Nous réalisons des plateformes Internet en un temps record, en mêlant talents et méthodologies agiles.

à lire