Maintenir les rejets / branches dans un rythme «agile»? [fermé]

Question

Nous avons un logiciel qui évolue au rythme des besoins des clients et d’une feuille de route plus générale.

Parce que nous sommes dans un environnement de projet SCRUM, il arrive très souvent qu’une nouvelle fonctionnalité fasse son chemin dans le produit, puis nous sommes confrontés au choix de:

• implémentant cette fonctionnalité dans une branche déjà publiée (ce n'est pas vraiment le point d'avoir une branche, alors)
• faire une nouvelle branche - mais alors nous avons une branche toutes les trois semaines, et ce n’est plus maintenable

Ne pas publier la nouvelle fonctionnalité n'est pas une option, les clients ne veulent pas attendre un plan d'étape à long terme pour obtenir les fonctionnalités qu'ils souhaitent, et il n'est pas toujours possible de déplacer la fonctionnalité dans un module client. besoin de changer le noyau du produit ...

Quelqu'un at-il un retour sur une bonne pratique compte tenu de ce type de contraintes?

Answer 1

Je suggérerais ce qui suit, que nous utilisons dans mon environnement actuel: traitez la fonctionnalité non planifiée comme un correctif de sécurité.

• Chaque version planifiée (par exemple, 3.0, 3.1) obtient son propre numéro de version et sa propre balise dans le code source. Après sa publication, vous n'y touchez pas.
• Les nouvelles fonctionnalités après une version planifiée sont intégrées à la prochaine version planifiée (par exemple 3.2)
• Si vous devez modifier une version publiée du code, il s'agit d'une "publication non planifiée". et obtient un numéro de version de correctif (par exemple, 3.1.1, 3.1.2). Toutes les modifications:
  • Implémentation dans une nouvelle branche basée sur le dernier correctif de cette version (par exemple, 3.1.1 est créé à partir de 3.1.0, 3.1.2 est créé à partir de 3.1.1)
  • Sont immédiatement fusionnés avec le tronc, ils entrent donc dans la prochaine version planifiée
• Après avoir implémenté la fonctionnalité non planifiée, transformez la branche en balise (ne plus y toucher plus) et recommencez à travailler dans le coffre.

Ainsi, chaque fonctionnalité non planifiée obtient une branche, mais uniquement le temps de créer une nouvelle version et d’être fusionnée dans trunk. Vous faites presque tout votre travail au même endroit - le coffre - et vous n’avez pas beaucoup de travail de fusion à faire.

Answer 2

Une nouvelle branche telle que ('new_feature_branch') est là pour matérialiser un effort de développement non compatible avec l'actuel branche (comme 'release_branch')

Ainsi, si votre release_branch actuelle n'est pas très active, vous pouvez l'utiliser pour la nouvelle fonctionnalité (à condition de définir une étiquette avant de développer cette nouvelle fonctionnalité, au cas où vous deviez annuler ce processus et passer à autre chose. retour à l'état précédent cette nouvelle fonctionnalité)

La création d’une nouvelle branche peut être une bonne solution, à condition qu’elle soit fusionnée régulièrement (toutes les 3 semaines) sur la branche de publication, puis qu’elle soit omise. Il est particulièrement recommandé si vous avez des activités sur le release_branch (comme des corrections de bugs à chaud). alors les deux efforts doivent rester séparés.

En gros, tout dépend de votre définition de flux de travail .

Laissez des commentaires si vous souhaitez que je détaille certaines options que vous estimez ne pas avoir été suffisamment approfondies.

Answer 3

Dans mon bureau, nous travaillons généralement dans 3 succursales à un moment donné.

• Release: C'est ici que le code actuellement déployé est marqué et stocké. Si nous devons faire des corrections de bogues critiques, c'est ici que le travail est effectué. Une fois déployé, nous incrémentons généralement la partie de correctif de l’étiquette (c.-à-d. 1.19.0 - > 1.19.1).
• QA: C’est ici que le code qui se prépare pour les clients est étiqueté et stocké. Cette branche est utilisée lorsque nous commençons un nouveau travail et que nous avons un code qui est actuellement testé par le service d’assurance qualité en vue de la prochaine livraison.
• Main: C’est là que tout nouveau travail est effectué.

Dans de rares cas où nous avons besoin de développer une quatrième ligne (en raison de calendriers de publication très serrés), nous ouvrons occasionnellement notre ligne de code sandbox. Plus généralement, un seul développeur travaillera de manière isolée et ne s'enregistrera pas tant que la ligne principale n'aura pas été effacée.

Avec la stratégie de branchement ci-dessus, nous avons été en mesure d'apporter des modifications importantes aux fonctionnalités avec une diffusion à la fin de chaque sprint.

Answer 4

Il ne semble pas que vous viviez vraiment dans un environnement Scrum. Scrum exige que l'équipe soit FAITE à la fin de chaque sprint, ce qui ne devrait pas durer plus de quatre semaines (plus probablement une à deux semaines). Ainsi, toutes les deux semaines, vous devriez de toute façon disposer d’un système entièrement déployé, testé et en cours d’exécution.

La seule façon pour moi de le faire est de disposer de suites complètes et entièrement automatisées de tests pour les clients et les développeurs (comme le recommande Extreme Programming).

Je ne suis pas sûr de savoir pourquoi vous auriez besoin de branches dans ce cas, mais je ne comprends pas non plus pourquoi cela ne serait pas maintenable. D'après mon expérience, plus une branche est courte, mieux c'est.