Pour la petite private joke du titre, ça se passe sur LinkedIn ;)
Aujourd'hui je te parle de TBD et de continuous intégration.
"Trop de features branches, et plein de PR, c'est n'importe quoi ! Vous faites de la merde, faut faire du trunk-based development pour faire du continuous intégration !" Oui...mais non 👇
- Alors ça c'est la première PR à review.
- Et ça c'est la deuxième. Attends, non en fait. Faut que je la rebase d'abord.
- Rebase : le "theirs" c'est le "mine" dans un merge c'est ça ? Putain je sais jamais...
Cet enfer on l'a tous connu. Et c'est lié au même problème : la divergence des changements.
S'ensuit le "merge hell" ou le "rebase hell".
La solution ?
👉 Commit régulièrement directement sur main. Problème réglé !
C'est ce qu'on appelle le continuous intégration : intégrer régulièrement sur main le code, pour éviter que celui-ci ne diverge trop pour les collègues.
Dans git, ça implique de faire du trunk-based development (TBD), chaque développeur commit directement sur main, sans PR.
Mais attention aux pieges !
👉 le continuous intégration implique le TBD
↪️ le TBD implique de travailler en tout petit batch, pour intégrer les changement sur main plusieurs fois par jour
↪️ avoir plusieurs changements par jour intégrés implique de travailler de façon incrémentale et itérative, sans PR, avec du pair-programming
↪️ travailler de façon incrémentale et itérative implique d'avoir des systèmes de feature toggle, ou de "path" caché pour activer/cacher des features.
↪️ travailler de façon incrémentale et itérative implique d'avoir une confiance aveugle dans la pipeline d'intégration (i.e : les tests auto)
↪️ avoir confiance dans les tests auto implique de savoir écrire ces tests, et donc savoir comment écrire du code testable
↪️ avoir du code testable implique de comprendre ce qu'est une bonne architecture logicielle
↪️ enfin, établir une architecture logicielle pérenne implique de l'excellence technique.
👉 En somme : le continuous intégration implique l'excellence technique. Mais aussi l'excellence côté produit. La "vraie" agilité.
🙅 Tenter d'appliquer tout ça du jour au lendemain c'est la recette assurée du désastre !
Voici quelques pistes pour améliorer le process de ton équipe :
✅ utilise une seule branche principale, main, par exemple
✅ utilise des features branches qui ne partent QUE de main
✅ garde la durée de vie de ces features branches la plus courte possible (idéalement une journée pas plus, voire deux)
✅ découpe en petites taches techniques les stories pour aller dans ce sens
✅ challenge le produit pour découper au mieux les trop grosses tâches pour arriver à des incréments testables
✅ dès que tu repères une régression, c'est l'occasion d'améliorer ta stratégie de tests automatisés, pour tendre vers plus de sécurité
✅ utilise le principe d'inversion de dépendances pour rendre ton code plus testable
Partagez ce post
y'a trop de conflits dans ton code Daniel !
Partagez ce post
Hello !
Pour la petite private joke du titre, ça se passe sur LinkedIn ;)
Aujourd'hui je te parle de TBD et de continuous intégration.
"Trop de features branches, et plein de PR, c'est n'importe quoi ! Vous faites de la merde, faut faire du trunk-based development pour faire du continuous intégration !" Oui...mais non 👇
- Alors ça c'est la première PR à review.
- Et ça c'est la deuxième. Attends, non en fait. Faut que je la rebase d'abord.
- Rebase : le "theirs" c'est le "mine" dans un merge c'est ça ? Putain je sais jamais...
Cet enfer on l'a tous connu. Et c'est lié au même problème : la divergence des changements.
S'ensuit le "merge hell" ou le "rebase hell".
La solution ?
👉 Commit régulièrement directement sur main. Problème réglé !
C'est ce qu'on appelle le continuous intégration : intégrer régulièrement sur main le code, pour éviter que celui-ci ne diverge trop pour les collègues.
Dans git, ça implique de faire du trunk-based development (TBD), chaque développeur commit directement sur main, sans PR.
Mais attention aux pieges !
👉 le continuous intégration implique le TBD
↪️ le TBD implique de travailler en tout petit batch, pour intégrer les changement sur main plusieurs fois par jour
↪️ avoir plusieurs changements par jour intégrés implique de travailler de façon incrémentale et itérative, sans PR, avec du pair-programming
↪️ travailler de façon incrémentale et itérative implique d'avoir des systèmes de feature toggle, ou de "path" caché pour activer/cacher des features.
↪️ travailler de façon incrémentale et itérative implique d'avoir une confiance aveugle dans la pipeline d'intégration (i.e : les tests auto)
↪️ avoir confiance dans les tests auto implique de savoir écrire ces tests, et donc savoir comment écrire du code testable
↪️ avoir du code testable implique de comprendre ce qu'est une bonne architecture logicielle
↪️ enfin, établir une architecture logicielle pérenne implique de l'excellence technique.
👉 En somme : le continuous intégration implique l'excellence technique. Mais aussi l'excellence côté produit. La "vraie" agilité.
🙅 Tenter d'appliquer tout ça du jour au lendemain c'est la recette assurée du désastre !
Voici quelques pistes pour améliorer le process de ton équipe :
✅ utilise une seule branche principale, main, par exemple
✅ utilise des features branches qui ne partent QUE de main
✅ garde la durée de vie de ces features branches la plus courte possible (idéalement une journée pas plus, voire deux)
✅ découpe en petites taches techniques les stories pour aller dans ce sens
✅ challenge le produit pour découper au mieux les trop grosses tâches pour arriver à des incréments testables
✅ dès que tu repères une régression, c'est l'occasion d'améliorer ta stratégie de tests automatisés, pour tendre vers plus de sécurité
✅ utilise le principe d'inversion de dépendances pour rendre ton code plus testable
Teste tout ça petit à petit avec ton équipe :)
Happy Coding !
Pierre.