Quelles sont les meilleures pratiques de GitLab Flow ?

Lorsque les équipes de développement logiciel s'empressent d'accélérer la livraison, elles risquent de se retrouver avec des workflows désordonnés ou complexes. Les organisations qui ont changé de système de contrôle de version sont particulièrement susceptibles de faire face à des processus difficiles qui peuvent ralentir le développement. Lorsque les équipes utilisent GitLab Flow, elles peuvent utiliser un développement axé sur les fonctionnalités et des branches de fonctionnalités dotées d'une gestion des tickets pour s'assurer que chaque membre de l'équipe travaille efficacement. Grâce à ces conseils sur GitLab Flow, les équipes de développement logiciel pourront simplifier le processus et produire un résultat plus efficace et plus propre.

L'utilisation de branches de fonctionnalités est un moyen simple de développer et de garder un code source propre. Si une équipe est récemment passée de SVN à Git, par exemple, elle sera habituée à un workflow basé sur le tronc. Lors de l'utilisation de Git, les développeurs doivent créer une branche pour tout ce sur quoi ils travaillent afin que les contributeurs puissent facilement démarrer le processus de revue de code avant de fusionner.

Certains développeurs ont configuré leur CI pour ne tester que ce qui a été fusionné dans la branche main, mais c'est trop tard dans le cycle de vie du développement logiciel. Des développeurs aux chefs de produit, tout le monde devrait avoir la certitude que la branche main possède toujours des tests verts. Il ne sert à rien pour les développeurs de tester la branche main avant de commencer à développer de nouvelles fonctionnalités.

Lorsque vous travaillez sur une branche feature et que vous ajoutez de nouvelles validations, exécutez des tests immédiatement. Si les tests prennent beaucoup de temps, essayez de les exécuter en parallèle. Effectuez cette opération côté serveur dans les merge requests, en exécutant la suite de tests complète. S'il existe une suite de tests pour le développement et une autre uniquement pour les nouvelles versions, il peut être intéressant de mettre en place des tests [parallèles] et de les exécuter tous.

Ne testez pas tout à la fin d'une semaine ou d'un projet. Les revues de code doivent avoir lieu dès que possible, car les développeurs sont plus susceptibles d'identifier les points qui pourraient causer des problèmes plus tard dans le cycle de vie. En détectant les problèmes plus tôt, ils auront plus de facilité à créer des solutions.

Si les développeurs ne souhaitent pas déployer la branche main à chaque fois, ils peuvent créer une branche production. Plutôt que d'utiliser un script ou de le faire manuellement, les équipes peuvent utiliser l'automatisation ou avoir une branche spécifique qui déclenche un déploiement de production.

Les développeurs doivent utiliser des tags afin que l'intégration continue effectue une action plutôt que de lui demander de modifier le dépôt. Si les équipes ont besoin de métriques détaillées, elles doivent disposer d'un rapport sur le serveur détaillant les nouvelles versions.

Chaque étiquette doit créer une nouvelle release. Cette pratique garantit un environnement de développement propre et efficace.

Lorsqu'ils poussent vers une branche publique, les développeurs ne doivent pas la rebaser, car cela complique l'identification des résultats des améliorations et des tests, tout en effectuant un cherry-pick. Parfois, ce conseil peut être ignoré lorsque vous demandez à quelqu'un d'effectuer un squash et de rebaser à la fin d'un processus de revue de code pour faciliter le retour à une version antérieure. Cependant, en général, la directive est la suivante : le code doit être propre et l'historique doit être réaliste.

Cette astuce empêche les longues branches. Les développeurs exécutent la commande git checkout sur la branche main, construisent une fonctionnalité, créent une requête de fusion et ciblent à nouveau la branche main. Ils doivent effectuer une revue complète avant de fusionner et d'éliminer toute étape intermédiaire.

Après avoir identifié un bogue, il serait problématique de le corriger dans la release qui vient de sortir et de ne pas le corriger dans la version main. Pour l'éviter, les développeurs devraient toujours corriger en poussant la modification dans la branche main, puis en effectuant un cherry-picking dans une autre branche patch-release.

Les développeurs doivent non seulement dire ce qu'ils ont fait, mais aussi pourquoi ils l'ont fait. Une tactique encore plus utile consiste à expliquer pourquoi cette option a été sélectionnée par rapport à d'autres pour aider les futurs contributeurs à comprendre le processus de développement. La rédaction de messages de validation détaillés est utile pour les revues de code et les développements futurs.