Pour les équipes de développement logiciel Agile et DevOps, Git est LE système de contrôle de version et occupe une place essentielle dans une chaîne d'outils DevOps. Ce projet open source bien pris en charge est suffisamment flexible pour être compatible avec 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 et DevOps. Considérez Git comme une composante du développement Agile et DevOps : 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 vos équipes Agile et DevOps (qui devraient s'efforcer de poursuivre sur leur lancée).
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.
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 livraison, par exemple. Cela permet aux développeurs de stabiliser et de renforcer le travail planifié pour une livraison spécifique, sans bloquer les autres développeurs qui travaillent sur de futures livraisons.
Une fois la branche de livraisons 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 livraisons. Pour réduire les coûts, il est préférable de créer la branche de livraisons aussi près que possible de la date de livraison prévue.
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 et DevOps performantes pratiquent les revues de code et configurent des tests automatisés (intégration continue ou livraison continue). 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 aucun problème. Cela facilite le reclassement des corrections de bug 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é.
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, lorsque vous mergez du code à l'aide de pull requests lorsque le code est terminé, vous disposez des documents nécessaires qui attestent que votre travail est fonctionnel, 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.
L'adoption d'un rythme de livraison régulier est la clé du développement Agile. Afin que Git soit adapté à 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.
