Comment se débarrasser de la branche de développement pour un flux Git simplifié

Dans un projet Web développé en continu (pas un produit), nous avons actuellement la stratégie de branchement suivante, basée en gros sur Git Flow :

• développer la branche: dernière version de travail
• branche principale: version à publier / version publiée
• branches de fonctionnalités: fonctionnalités en développement
• branches de correctifs: corrections de bogues urgentes dans la version publiée

Master est en lecture seule, mis à jour via les demandes d'extraction des branches de développement ou de correctif . Chaque mise à jour entraîne la création et le déploiement d'une version candidate sur le système intermédiaire. Les candidats aux versions sont déployés en production après approbation manuelle.

Les branches de fonctionnalités sont créées en fonction du développement ou de la dernière validation qui a été fusionnée dans master. Une demande d'extraction d'une branche de fonctionnalité à développer est créée, déployée sur un système de test gratuit où les tests d'intégration et les tests d'acceptation (automatiques et manuels) sont exécutés. Lorsqu'il est testé et révisé avec succès, le PR est fusionné, de sorte qu'il fera partie de la prochaine version (c'est-à-dire qu'il fusionnera du développement au master).

Mon but

Je voudrais simplifier cela et me débarrasser de la branche develop. La branche develop a principalement des raisons historiques et comme c'est toujours une version testée avec succès, je pense qu'il n'est pas nécessaire de la séparer de master. La supprimer simplifiera également le processus de publication car il n'y a plus de fusion supplémentaire.

J'ai les contraintes suivantes:

• les sorties sont programmées et ne devraient pas être entièrement automatisées
• Bien que les branches de fonctionnalités soient généralement de courte durée, certaines restent non fusionnées pendant plusieurs semaines (par exemple une refonte) mais doivent également être testées (actuellement sous forme de demandes de tirage ouvertes à développer)
• parfois, une seule fonctionnalité doit être publiée en dehors de la version régulière, ce qui en fait un correctif. Avec la stratégie actuelle, je peux rebaser une branche de fonctionnalité et la fusionner directement dans le maître
• il arrive également que nous devions retenir les fonctionnalités après l'échec des tests d'acceptation avec des systèmes externes sur la mise en scène

Où je ne suis pas sûr de la transition:

• actuellement, je crée des demandes d'extraction pour les tests et les commits de fusion pour les versions. Puis-je unifier cela?
• comment gérer les correctifs lorsque le maître est en avance sur la dernière version. Dois-je créer et déployer des versions directement à partir de branches de correctifs?
• Existe-t-il un moyen judicieux de gérer les fonctionnalités qui devraient être exclues d'une version après avoir été fusionnées? Une branche de développement distincte est-elle vraiment un avantage pour ces cas? La plupart du temps, je reviens et reviens à la fin manuellement.

À mon humble avis, les problèmes auxquels vous êtes confrontés ne sont qu'un effet secondaire de la mauvaise stratégie de branche avec laquelle vous avez commencé: vous labourez efficacement de nouveaux développements develop(c'est-à-dire ce qui converge vers le futur code de production) via le code de production actuelmaster . Cela conduit à des exigences et à des problèmes contradictoires car typiquement le futur code diverge de l'actuel:

• le nouveau développement déstabilise la production - régressions observées après la fusion developenmaster
• la stabilisation de la production ralentit le développement futur - vous devez vous stabiliser developpour le rendre suffisamment bon pour fusionner enmaster

La suppression developn'aidera pas (beaucoup) - vous n'éliminez pas le problème, vous transférez simplement la developpartie spécifique du problème dans master.

Une meilleure approche serait de déplacer la production derrière le développement actuel / futur, pour éviter toute interférence avec le développement pour les futures versions, comme illustré dans cette image de What is Your Branching Model? :

Veuillez noter que je ne fais référence qu'aux branches de publication dans l'image ci-dessus, pas à ce qui se passe dans le coffre.

Comment cela fonctionnerait-il pour vous:

• la developbranche disparaît, comme vous le souhaitiez, absorbée dansmaster
• la masterbranche est votre tronc, c'est là que le développement se produit sans restriction de vitesse (il n'est jamais fusionné en production).
• la production est / sont une ou plusieurs releasebranches tirées d'une masterétiquette / étiquette considérées comme suffisamment proches de la qualité de la production (une courte liste des tâches restantes peut être adressée dans cette branche si nécessaire). Ces branches ne peuvent recevoir que des correctifs directs et / ou des correctifs choisis par les cerises master, elles ne sont jamais fusionnées avec masterou avec d' autres branches
• les correctifs sont des validations directes dans les releasebranches

Si un correctif s'applique uniquement à une version de production mais pas à la version, masteril est directement validé dans la releasebranche. S'il s'applique aux deux, il est généralement validé en masterpremier et également sélectionné en double pour la releasebranche.

Maintenant, en regardant ce qui se passe master(qui est passé le point où la releasebranche actuelle est retirée), vous avez 2 options:

• continuez avec les branches de fonctionnalités comme vous le faites aujourd'hui, sauf qu'elles seront basées master, non develop. Les convertir en correctifs reste possible - il vous suffit de les rebaser dans la releasebranche correspondante au lieu demaster
• basculez vers une intégration continue et profitez de ses avantages (cela peut être fait à tout moment), y compris de manière progressive - tirez progressivement de moins en moins de branches de fonctionnalités.

Si vous aimez cette approche, voici comment vous y rendre d'où vous êtes aujourd'hui:

• établir une stratégie de dénomination des versions:
  • vous ne pouvez pas avoir une branche de publication en cours avec le même nom
  • vous ne pouvez pas (ne devriez pas réellement) rebaser ou synchroniser une branche de version de production
• tirer une releaseXbranche masterimmédiatement, en suivant cette stratégie de dénomination
• arrêter les commits d'entrer develop, ils iront bientôt directement master.
• fusionner developdansmaster
• demander aux développeurs de rebaser leurs espaces de travail au masterlieu de develop.
• ouvert masteraux commits
• supprimer developsi vous le souhaitez (ou le laisser verrouillé en permanence / en lecture seule pour référence)

Supposons que vous supprimez la branche master (vous pouvez renommer develop en master pour confondre votre équipe si vous le souhaitez plus tard) et simplement utiliser des balises pour les versions sur les branches develop ou hotfix. Vous avez supprimé une branche, mais la différence n'est qu'un changement de syntaxe. Changez pour changer.

Supposons maintenant que vous supprimez réellement le développement en conservant la branche principale verrouillée. Ce qui se passera, c'est que l'intégration du code ralentira, il vivra plus longtemps séparé dans les branches de fonctionnalités, en particulier à proximité des dates de sortie. Cela augmentera la difficulté de fusionner à chaque fois et ralentira le processus.

Compte tenu des contraintes que vous avez fixées, je ne vois aucun effet positif à apporter un tel changement. Il faudrait assouplir les contraintes, notamment la première.

Vous créez et testez déjà du code sur chacune des branches pull-request et hot-fix. Cela signifie que dans l'ensemble, la somme de toutes les branches en attente de pull-request est votre developbranche virtuelle .

Vous pouvez créer un système lorsque, dans un environnement de test, plusieurs pull-requests sont sélectionnées dans une branche temporaire qui n'est pas publiée dans le référentiel principal. Cette branche est utilisée pour intégrer un environnement de test qui inclut masteret plusieurs pull-requests supplémentaires, mais une fois le test terminé, cette branche n'est plus disponible nulle part.

Lorsque vous créez une version à partir de master, vous créez généralement une balise sur cette version. Les correctifs ultérieurs peuvent utiliser cette balise pour créer une nouvelle branche de correctifs à partir de laquelle un déploiement sera effectué, même si le bord de masterest déjà en avance. Sur cette branche de correctif, vous marqueriez probablement également une version mineure et vous assurer que les modifications ont été fusionnées master.

La suppression des fonctionnalités fusionnées d'une version est assez difficile à faire avec git. Le meilleur mécanisme pour cela serait d'utiliser git revertle commit de fusion. Mais cela rend presque impossible de récupérer ces fonctionnalités / changements, et l'histoire devient tout confuse.

Les indicateurs de fonctionnalité constituent une bien meilleure façon de gérer la séparation pour le déploiement de code et la publication de fonctionnalités . Si vos développeurs peuvent masquer leurs fonctionnalités derrière certaines conditions dans le code lui-même, vous pouvez déployer leur code, mais désactivez la fonctionnalité. Il s'agit d'un sujet distinct, mais de nombreuses informations à ce sujet existent (y compris un Q&A sur devops.SE).

Eh bien @ dan-cornilescu le dit bien pour votre problème particulier, mais le cas plus général pour le développement basé sur le tronc (mentionné dans la livraison continue, Lean Enterprise et le manuel DevOps) est présenté ici: https://trunkbaseddevelopment.com/