Dans un monde où un produit, pour vivre, doit être concurrentiel et s’améliorer continuellement, l’agilité est devenue un incontournable. Si l’agilité permet d’éviter le fameux « effet tunnel » et de s’adapter rapidement aux nombreuses demandes et changements des métiers, elle ne peut pas faire de miracles concernant l’intégration et le déploiement de fonctionnalités. En effet, outiller les développeurs et automatiser un certain nombre d’étapes de la conceptualisation à la livraison reste la clé d’une amélioration continue, d’un avantage concurrentiel et d’une qualité de service irréprochable.
Des outils existent depuis un bon nombre d’années, permettant de faciliter la collaboration des équipes de développement. On peut par exemple citer Git (sur lequel se base les solutions du marché), permettant le stockage et la revue du code source en ligne, ainsi que l’archivage des anciennes versions. Si l’usage de Git semble aujourd’hui évident au sein d’une équipe de développement, l’art et la manière de l’utiliser l’est moins. Git est conçu pour exploiter ce que l’on appelle une branche.
Ces branches étant des lignes de développement isolées, elles offrent donc à chaque développeur un environnement de travail personnel, sourcé sur une base commune à toute l’équipe, nommé le master (ou main). Cet outil permet aux équipes de développement de collaborer facilement, sans se marcher sur les pieds. Quand un développeur crée une branche, il crée une copie du code source à cet instant donné.
Quel lien avec l’automatisation de déploiement me direz-vous ? C’est ce que nous allons détailler aujourd’hui.
LE DEPLOIEMENT CONTINU, L’AGILITE MAXIMISEE
Comme nous le disions, l’agilité a pour principe de satisfaire le client au travers de livraisons rapides et continues. Portée par les approches CI/CD (Continuous Integration, Continuous Deployment) et associée à un bon nombre de concepts – sprints, user story, tâches – voyons comment cette gestion de branche peut devenir une force.
Plusieurs stratégies de gestions de branches existent, et chacune possède ses variantes : GitFlow, GitHub Flow, GitLab Flow, Trunk Base Development (TBD). Elles sont souvent sujettes à débat au sein des communautés de développement.
Le thème principal du débat est le cycle de vie d’une branche et donc à quel moment il faut « merge sur le master », c’est à dire fusionner les nouveaux éléments que l’on a développé sur sa branche à la base commune.
GitFlow se concentre sur une branche de développement qui vit en parallèle de notre master.
Autrefois utilisé massivement, la volonté d’intégration continue plus récurrente (plusieurs fois par jour) liée à la complexité de gérer une si grosse branche pour des petits changements ont poussé les développeurs à se pencher sur les approches dites trunk based.
Le TBD, approche trunk based la plus connue, a pour principe fondamental de pouvoir déployer le master en production à tout moment.
Vous trouverez généralement, au sein des approches TBD, une branche de livraison (release), une branche de fonctionnalité (feature) et une branche de correctifs (hotfix), en complément du master. Chaque fonctionnalité une fois testée et validée vient s’ajouter au master, jusqu’à ce qu’on paquète le tout dans une « release » sur la branche de livraison, en vue du déploiement. La branche de correctifs fonctionne comme celle des fonctionnalités, mais étant dédiée aux correctifs, son cycle de vie diffère.
Portée à l’agilité, où l’on a l’habitude de découper le travail en petits tâches, notamment avec des outils de suivi de projet, l’avantage des approches trunk based va être la facilité à faire correspondre une branche avec un type d’item de votre backlog. Typiquement une branche de :
- feature porte une user story
- hotfix porte le correctif d’un bug
- release porte l’ensemble des features testées et validées par vos PO.
On peut donc aussi synchroniser le merge des features ou la création de la branche de release avec la Definition of Done (DoD) du projet en fonction de votre organisation.
Le fait que chaque modification soit nichée sur sa propre branche permet d’immédiatement identifier ce qui est en cours et ce qui est prêt à être livré. Le cycle de vie des branches de features et hotfix doit être le plus court possible, rendant le merge plus simple, et plus flexible sur le master.
Rappelez-vous, en créant une branche, vous créez un espace où travailler, sans affecter ce que vous pouvez livrer. Vous offrez une chance à vos collaborateurs de passer en revue votre code, et vous assurez que le master correspond à une source de vérité pour toute l’équipe.
Pour gérer les changements qui ne peuvent pas avoir un cycle de vie court correspondant à une branche de features, on peut choisir de détourner l’usage des features flag, ou de construire une branche par abstraction, nous en reparlerons une prochaine fois.
Bien entendu, le « branching » n’est pas une panacée et peut-être discuté, mais il présente bien assez d’avantages pour regarder ce qui se passe du côté de vos équipes de développement ; avantages qui répondront souvent au besoin de vos équipes métiers, parfois même plus qu’à ceux de vos équipes techniques !
Chez Arsia Mons nous n’oublions pas ces sujets d’excellence opérationnelle dans le cadre de nos transformations agile. N’hésitez pas à nous contacter pour plus d’informations !
Commentaires récents