Git facilite considérablement le développement de logiciels

Trois conseils pour que Git s'intègre dans votre workflow Agile (et vice versa)

Laura Daly Laura Daly
Parcourir les rubriques

Git est, de facto, un standard dans le développement Agile lorsqu'il est question de systèmes de contrôle de version. Ce projet open source bien pris en charge est suffisamment flexible pour prendre en charge une série de workflows qui répondent aux besoins de n'importe quelle équipe de développement. Sa nature distribuée, plutôt que centralisée, lui confère des caractéristiques de performances supérieures, et permet aux développeurs d'expérimenter localement et de publier leurs changements uniquement lorsqu'ils sont prêts à être distribués à l'équipe.

Outre les avantages en matière de flexibilité et de distribution, Git dispose de fonctions clés qui soutiennent et améliorent le développement Agile. Considérez Git comme une composante du développement Agile ; les changements peuvent être pushés plus rapidement vers le pipeline de déploiement qu'en travaillant avec des livraisons monolithiques et des systèmes de contrôle de version centralisés. Git fonctionne de la même manière que votre équipe Agile (qui devrait s'efforcer de poursuivre sur sa lancée). 

Conseil de pro :

Git est un système de contrôle de version décentralisé (DVCS). Contrairement aux dépôts CVS ou Subversion (SVN), Git permet aux développeurs de créer leur propre copie personnelle du dépôt de l'équipe, hébergé en parallèle de la base de code. Ces copies sont appelées des forks, et lorsque le travail est terminé sur un fork, il est facile de faire un push des changements vers la base de code principale.

Création de branches Git | Atlassian – Le coach Agile

Astuce n° 1 : Considérez les tâches comme des branches Git

Git entre en jeu après que les fonctionnalités ont été étoffées, ajoutées à une feuille de route produit, et que l'équipe de développement est prête. Mais pour prendre du recul, il existe un cours accéléré sur le développement de fonctionnalités Agile : les équipes produit, de design, d'assurance qualité (QA) et d'ingénierie organisent une réunion de lancement de la fonctionnalité afin de parvenir à une compréhension commune de ce que sera la fonctionnalité (penser aux exigences), du périmètre du projet et des tâches qui doivent être réparties pour la réaliser. Ces tâches, également appelées user stories, sont ensuite assignées à des développeurs individuels.

À ce stade, Git commence à s'intégrer à votre workflow Agile. Chez Atlassian, nous créons une branche pour chaque ticket. Qu'il s'agisse d'une nouvelle fonctionnalité, d'une correction de bug ou d'une petite amélioration de code existant, chaque changement apporté au code a sa propre branche.

La création de branches est directe et permet aux équipes de collaborer facilement dans une base de code centrale. Lorsqu'un développeur crée une branche, il dispose de sa propre version isolée de la base de code dans laquelle apporter des changements. Pour une équipe Agile, cela implique qu'en décomposant les fonctionnalités en user stories puis en branches, l'équipe de développement peut réaliser les tâches individuellement et travailler plus efficacement sur le même code, mais dans des dépôts différents. Cela évite les doublons et, puisque les personnes peuvent se concentrer sur des petits blocs de travail dans des dépôts séparés du dépôt principal, le nombre de dépendances ralentissant le processus de développement est réduit. 

Conseil de pro :

Il existe d'autres types de création de branches Git en plus des branches de tâche, et ils ne s'excluent pas mutuellement. Vous pouvez créer des branches pour une version, par exemple. Cela permet aux développeurs de stabiliser et de renforcer le travail planifié pour une version spécifique, sans bloquer les autres développeurs qui travaillent sur de futures versions.

 

Une fois la branche de livraison créée, vous devrez la merger régulièrement dans votre branche principale pour garantir que votre travail sur la fonctionnalité soit pris en compte dans les prochaines versions. Pour réduire les coûts, il est préférable de créer la branche de livraison aussi près que possible de la date de livraison prévue. 

Vue détaillée d'une branche Git | Atlassian – Le coach Agile

Conseil n° 2 : Plusieurs branches peuvent être testées individuellement, profitez-en

Lorsque les branches sont considérées comme terminées et prêtes pour les revues de code, Git joue un autre rôle clé dans un workflow de développement Agile : il gère les tests. Les équipes Agile performantes pratiquent les revues de code et configurent des tests automatisés (intégration continue ou développement continu). Pour faciliter les revues de code et les tests, les développeurs peuvent facilement informer le reste de leur équipe que la branche est prête à être examinée et qu'elle doit être passée en revue via une pull request. Plus simplement, une pull request est une façon d'indiquer à un autre développeur qu'une de vos branches peut être mergée dans la branche principale et qu'elle est prête à être testée.

Avec les bons outils, votre serveur d'intégration continue peut faire un build de vos pull requests et les tester avant de les merger. Vous êtes ainsi certain que votre merge ne provoquera pas de problèmes. Cela facilite le reclassement des correctifs de bugs et des conflits en général, car Git connaît la différence entre la branche et la base de code principale depuis que les branches ont divergé. 

Conseil de pro :

Une branche de fonctionnalité longue, qui n'est pas mergée dans la branche principale, peut nuire à votre capacité à être agile et à itérer. Si vous avez une branche de fonctionnalité longue, souvenez-vous que vous avez en fait deux versions divergentes de votre base de code, ce qui entraînera plus de corrections de bugs et de conflits. Mais la meilleure solution consiste à avoir des branches de fonctionnalité éphémères. Pour ce faire, décomposez les user stories en plus petites tâches, planifiez soigneusement les sprints et mergez le code de façon anticipée afin de le livrer sous forme de fonctionnalités masquées. 

Conseil n° 3 : Git fournit transparence et qualité au développement Agile

Git/Agile est, par nature, axé sur l'efficacité, les tests, l'automatisation et l'agilité en général. Une fois que vous avez mergé une branche dans la branche principale, votre workflow Agile est terminé. De même, merger du code à l'aide de pull requests signifie que lorsque le code est terminé, vous disposez des documents nécessaires pour avoir la certitude que votre travail est passé à l'état terminé (vert), que les autres membres de l'équipe ont approuvé le code et qu'il est prêt à être livré. Cela permet aux équipes Agile d'avancer à la vitesse et avec la confiance nécessaires pour livrer souvent : c'est le signe d'une grande équipe Agile.

Conseil de pro :

L'adoption d'un rythme de livraison régulier est la clé du développement Agile. Afin de faire fonctionner Git pour votre workflow Agile, vous devez vous assurer que votre branche principale est toujours fonctionnelle. Autrement dit, si une fonctionnalité n'est pas prête, attendez la prochaine livraison. Si vous adoptez des cycles de livraison plus courts, cela ne devrait pas être un gros problème.

suivant
Branching