À la MAIF, le flow de dév le plus communément appliqué, c'est du gitflow et du scrum. Personnellement, j'ai du mal à comprendre le gitflow et je ne comprends pas à quoi sert la branche develop du moins pour le développement d'application. Les branches support ne sont pas utiles car, on ne maintient qu'une version de notre application à un moment donné. J'ai également l'impression que la branche master et develop finissent obligatoirement par avoir un historique divergent, à moins de rebase develop à partir de master de faire un force push.

En ce qui concerne le scrum, je trouve que ça génère une pression continue, on est toujours en train de se prendre la tête sur les stories pour savoir si ça va rentrer ou non dans le sprint. Ça n'est pas très chill comme méthode.

Depuis quelques années sur notre projet, nous avons mis en place un flow un peu atypique à base de trunk base. C'est ce que je vais vous présenter ici.

Dans les langages fonctionnels tels que java ou haskell, il est d'usage d'utiliser au maximum le compilateur pour éviter le plus tôt possible les bugs.

Avec l'arrivée du jdk 17, et notamment des sealed class et des record, java nous propose de nouvelles fonctionnalités pour utiliser encore plus le système de type et donc le compilateur.

L'approche "parse, don't validate" propose de créer des types riches pour représenter les données plutôt que d'utiliser les types primitifs comme String, Boolean etc et ainsi rendre impossible les états incohérents. Dans le cas d'une API, une fois le payload d'une requête parsé, c'est le compilateur qui reprend la main et valide le code pour vous.

Dans cet article, je vous propose, de suivre cette pratique en java et de voir où ça nous mène.