Stratégie de branchement Gitflow, mais sans la Développement de la branche
Je pense à adopter quelque chose comme la stratégie de ramification Gitflow. Au lieu d'utiliser une branche permanente develop, je voudrais créer une branche release pour chaque sprint (à partir de master) au début de chaque sprint. Les branches de fonctionnalités seraient fusionnées dans la branche de sortie. Notre processus CI (TeamCity) serait configuré pour déployer la dernière branche de version (basé sur le suffixe de numéro de version) à nos environnements d'intégration et d'assurance qualité.
Mon idée ici est que nous éviterions la nécessité de maintenir une succursale develop et d'éviter la nécessité de fusionner dans masteretdevelop lors d'une version est prêt.
Serait-il des inconvénients potentiels de cette approche?
Clarifier:
- le cycle de sprint/libération est typiquement ~ 3 semaines
- nous avons besoin de la possibilité de libérer occasionnellement une seule branche de fonctionnalité, qui peut déjà avoir été fusionnée dans la branche de sortie.
Il y a des inconvénients, je ne vois pas autant d'avantages.
Je ne sais pas comment vous évitez de la nécessité de fusionner dans Master, à moins que Master ne cesse de refléter la "dernière version publiée"
Le principal inconvénient que je vois, c'est que vous obtenez un comportement "Développer", mais changer le nom de votre "développement" sur chaque sprint et que votre CI doit pointer sur une branche différente de chaque sprint.
Le deuxième plus gros inconvénient à mon avis, corrige des bugs. Lors de la répartition des bugs sur une version plus ancienne, vous devrez les porter à la version actuelle (et probablement quelques sorties intermédiaires, si les clients utilisent différentes versions). Vous avez fabriqué ce processus plus difficile avec votre structure de branche, gérant potentiellement de nombreux autres agences d'intégration.
Si vous essayez d'éviter de la fusion, vous n'allez pas bénéficier de la ramification.
Sa me semble que vous êtes toujours en train de faire GitFlow vous êtes juste embêtez avec la dénomination de la branche se développer.
Maintenant, il y a un problème majeur ici. Pas tant avec le changement de nom/rebranching mais avec votre choix de nom.
Vous souhaitez nommer la branche avec la version de la version. Cependant, vous ne pouvez pas connaître la version de version avant d'arriver au point de sortie.
par exemple:
Vous appelez votre branche version_1.0.0.2 mais avant de la finir, vous devez faire une solution chaude! Maintenant, votre libération sera 1.0.0.3
Ok, vous décidez de quitter le numéro de construction et d'appeler la branche version_1.0.1.x Mais vous réalisez que l'une de vos fonctionnalités introduit un changement de rupture! maintenant vous voulez changer pour release_1.2.0.x
Vous démarrez une fonctionnalité de version_1.1.x.x mais elle n'est pas terminée à temps pour la fin du sprint. Maintenant, vous devez la fusionner dans la version_1.2.x.x
Dans l'ensemble, vous ferez mieux de branler vos branches de libération de Master lorsque vous les libérez plutôt qu'à l'avance et utilisez des éléments tels que les numéros de construction et le marquage généré automatiquement pour étiqueter vos versions de version dans Git/Source Control
Je peux bien comprendre que vous ne voulez pas maintenir la branche développée. Il agaçant de maintenir à la fois le maître et le développement. Nous avons aussi bien laissé tomber l'utilisation d'une succursale de développement. Nous assurons que le maître est toujours dans un état de travail. Seul le code potentiellement relutable passe en maître. Nous accomplissons cela à l'aide de branches de fonctionnalités.
Nous avons généralement publié du Master, mais nous avons eu des problèmes mineurs la dernière libération majeure où il n'était pas clair lorsque la "coupure" était ce qui a entraîné la libération non testée aussi bien que nous aurions aimé.
À l'avenir, nous parlons de libérer une succursale de libération au lieu de maître. Nous avons ces branches de publication aujourd'hui, mais aujourd'hui, nous la fusionnerons à maîtriser avant de libérer ce qui n'est pas optimal.
Immédiatement après une publication, la Direction de la version sera fusionnée à Master.
Le flux que vous décrivez des sons comme une configuration idéale et je ne vois aucun inconvénient majeur. À l'avenir, nous faisons probablement quelque chose de similaire.
Je crois que votre style de ramification devrait être basé sur votre stratégie de publication:
- Développement de produits/bibliothèques
- Communiqués à base de sprint
- Déploiement continu
Historiquement, je me suis concentré sur le développement des produits et des bibliothèques. Dans ce monde, vous avez généralement plusieurs versions dans une utilisation simultanée et que la mise en œuvre peut être considérablement différente entre les versions - de sorte que les fichiers de bugs pour une version ne puissent simplement pas être fusionnés dans une autre version. Pour soutenir cela, j'utilise la structure suivante:
- Branches de fonctionnalités: unités de travail individuelles, qui commencent dans le cadre d'une version mais peuvent ne pas se retrouver sur cette version.
- Une branche de libération, qui reçoit des commits écrasés des fonctionnalités (et est régulièrement fusionné dans les branches de fonctionnalité afin de minimiser les conflits).
- Master, qui contient Le plus récemment publié version du codebase.
La clé ici est qu'une succursale de publication vivra après avoir été fusionnée à la maîtrise et de recevoir des modifications pouvant exister ou non ailleurs. Donc, par exemple, pendant que vous travaillez sur la succursale rel_1_9, vous pouvez faire un bugfix sur rel_1_2 et balise que BugFix avec rel_1_2_7.
Dans cette approche, il n'y a aucun besoin de maîtrise: vous pouvez créer une nouvelle branche de version à partir de la balise de déverrouillage et la définir comme une branche par défaut. Mais certaines personnes aiment avoir master alors ...
L'environnement alternatif est celui où vous effectuez des versions régulières, mais jamais de retourner aux sorties plus anciennes (par exemple, une application hébergée typique). Dans ce cas, je pense que la stratégie de ramification dépend de la pratique du déploiement ou des sprints continus.
Pour les sprints, Développer est utile en tant que branche d'intégration: tous les nouveaux travaux sont fusionnés dans les branches de fonctionnalités, mais il ne se fusionne pas à maîtriser jusqu'à ce que le sprint soit terminé. Pendant le sprint, des corrections chaudes peuvent être engagées à maîtriser et ensuite fusionnées. Il n'y a vraiment aucune raison de créer des branches distinctes pour chaque version; Si la branche n'est jamais touchée après la fusion, elle est sémantiquement identique à une étiquette.
Et si vous faites du déploiement continu, je vous recommande de conserver la fonctionnalité et des maîtres succursales et de vous débarrasser du développement. Si vous avez plusieurs développeurs fusionnant leur travail dans le développement avant Master, vous Will Si vous avez une situation où des modifications involontaires sont fusionnées et déployées.
Auto-promotion sans scrupule: http://www.kdgregory.com/index.php?page=scm.git