Comment passer d'une réalité de branchement complexe à un modèle à branche unique?

Dans les grandes organisations, l'utilisation de la méthodologie de la cascade se traduit généralement par des structures de branchement très complexes (aka spagetti de branche ).

Quelles stratégies de branchement peuvent être utilisées pour passer d'une réalité de branchement complexe à un modèle à branche unique comme le développement basé sur un tronc?

Mise à jour:

Pour clarifier, la question concerne la migration / transition elle - même , pas les méthodologies avant et après, qui sont assez claires.

Cela ne peut pas vraiment être "à l'EOB aujourd'hui, nous sommes toujours en cascade avec des millions de branches, mais demain, la première chose que nous passerons au CI à base unique, à base de tronc".

Parce que vous mentionnez la cascade, je comprends que les nombreuses branches auxquelles vous faites allusion sont des branches de fonction plutôt que des branches de maintenance.

Dans cette configuration, je suppose également que ces branches sont créées selon un plan en cascade qui tente de minimiser les conflits. Cela implique que l'objectif du développement est de produire plusieurs produits distincts. Lorsque vous utilisez un modèle de développement à branche unique, il est important de travailler également sur un seul produit. Si plusieurs produits sont développés simultanément dans un modèle de développement à branche unique, il «colle» efficacement les versions de ces produits, afin que nous puissions avoir dans la version a du référentiel un produit sain X et un produit buggy Y , tandis que dans la version b le produit X a une régression et Y un correctif de bogue, mais nous n'avons pas de version où X etVous êtes en bonne santé. Une telle situation nous obligerait à considérer X et Y comme étant développés dans des référentiels distincts, ce qui est une indication qu'ils devraient l'être.

Par conséquent, les premières étapes doivent effectuer une division du référentiel :

1. Organisez le référentiel de sorte qu'il soit facile de le diviser en plusieurs petits référentiels. Par exemple, réorganisez le référentiel actuel afin que chaque répertoire de niveau supérieur corresponde à un référentiel que vous souhaitez créer à l'avenir. Ce faisant, vous pouvez continuer à utiliser la discipline branche-spaghetti que tout le monde connaît.

2. Une fois l'étape 1 terminée, affinez la discipline des branches-spaghettis en exigeant que chaque branche puisse toucher des fichiers dans un seul répertoire de niveau supérieur.

3. Lorsque chaque branche est conforme à l'étape 2, effectuez le fractionnement. Les développeurs peuvent facilement convertir leurs modifications en attente pour patcher un référentiel unique, simplement en supprimant le premier niveau du chemin.

Maintenant que la scission a été effectuée, vous pouvez commencer à travailler sur la discipline de branche elle-même.

4. Introduire des techniques de programmation aidant au développement de branches de courte durée. La courte durée de vie des branches est un aspect crucial de toutes les méthodologies à branche unique. L'un de leurs objectifs est de réduire le temps consacré à la fusion et au débogage des branches à longue durée de vie. Une technique populaire consiste à introduire des «indicateurs de fonctionnalité» où une «usine» utilise un indicateur de configuration pour produire la version historique d'un objet ou la nouvelle version, initialement partiellement développée, de cet objet.

5. À l'heure actuelle, vous avez des millions de référentiels avec seulement quelques branches dans chacun, et vous pouvez activer le bouton "nous adoptons globalement la discipline de développement basée sur le tronc", sans voir la montagne de branches-spaghetti d'origine s'effondrer sur le tronc.

La répartition réelle des référentiels peut être facultative, mais vous devrez alors adopter des politiques qui délimitent proprement la portée autorisée de chaque correctif soumis (pour limiter le risque de conflits lors de la fusion des modifications dans la branche principale). Réduire les frais généraux liés aux conflits est l'un des objectifs des méthodologies de modèle à branche unique, je suppose donc que cela est pertinent dans votre contexte.

Lors de la migration de quelque chose vers quelque chose d'autre, il n'y a que deux choses que vous devez définir:

1. Quelle est votre cible
2. Comment s'y rendre (le plan de migration)

La première partie est, malheureusement, souvent négligé ou chemin trop vague. Vous ne pouvez pas simplement dire que ce que vous avez est un gâchis et vous voulez l'organiser. Qu'est-ce que cela signifierait? Tout le monde aurait une interprétation différente (aka: tous les dev pense que son ou sa façon de faire est le meilleur).

Il y a de fortes chances que toutes les succursales que vous avez soient en service ou aient atteint un objectif. Sans un processus cible clairement défini, les gens continueront à faire ce qui leur convient le mieux (et à juste titre).

Par exemple, votre cible doit être définie aussi clairement que Vincent Driessen a défini son «modèle de branchement Git réussi» . Si vous regardez ce modèle, il est très précis: il indique où le code stable doit être, et où les fonctionnalités instables doivent être développées. Il indique également comment - et quand - créer une branche, mettre à jour et fusionner. Vous savez à quoi sert chaque branche et quoi en faire. Nous utilisons une variation de ce qui a été proposé par Vincent et notre variation est définie dans notre wiki.

L'important est que toute l'équipe comprenne et s'entende sur un objectif. Il pourrait être utile de rappeler aux gens que vous ne recherchez pas leur modèle de branchement préféré, mais un modèle sur lequel tous les membres de l'équipe peuvent s'entendre et utiliser facilement.

Une fois que vous avez votre cible, vous pourrez élaborer votre plan de migration. Ce plan peut être aussi long ou aussi court que vous le souhaitez. J'ai vu un tel modèle de ramification imposé du jour au lendemain; à d'autres endroits, cela s'est fait sur 2 ou 3 sprints. Peu m'importe, tant que nous nous améliorons.

Vous pouvez commencer par les branches "les plus grandes" ou les plus importantes. Par exemple: "à partir de maintenant, master doit toujours être dans un état pour être déployé dans prod et la branche dev doit toujours compiler" (ou quelles que soient vos règles). Ensuite, appliquez les branches de version (version). Ensuite, appliquez les branches de fonctionnalités. Après cela, imposez un gel de code sur la branche de version, si cela a du sens.

DevOps est une question de communication, d'ouverture et d'efficacité. Ces concepts doivent être gardés à l'esprit et communiqués tout au long du processus.

Je suggère d'inviter des personnes extérieures à l'équipe de développement à la réunion du processus en tant qu'observateurs. Les Ops ou les cadres intermédiaires pourraient avoir une ou deux choses à dire sur votre modèle. Les besoins des développeurs devraient être priorisés, mais si le modèle de branchement est impossible à aligner avec la façon dont les choses sont gérées, vous feriez mieux de le savoir maintenant et pas dans un mois ou deux.

Si vous avez de très grandes équipes, essayez néanmoins d'inclure tout le monde. Avec de très grandes équipes, vous vous retrouverez quand même avec deux ou trois rencontres. Invitez donc les chefs d'équipe dans la salle, mais ayez une webdiffusion disponible et informez-en tout le monde. Si quelqu'un a une suggestion ou une préoccupation, il pourra l'exprimer à son chef d'équipe et si elle est valable, elle sera traitée lors de la deuxième ou troisième réunion.

Il est en fait très simple de convertir un référentiel hydra à plusieurs branches en un modèle à une seule branche.

Tout d'abord, vous voulez commencer par les branches qui ont le moins de différence entre elles-mêmes et le maître ou le tronc. Examinez leur âge et leur pertinence. S'ils sont toujours pertinents, commencez à les fusionner et à résoudre les conflits. S'ils ne sont plus pertinents, supprimez-les.

Continuez ce processus jusqu'à ce que vous ayez réussi à fusionner toutes vos branches, résolu tous les conflits et qu'il ne vous reste qu'une seule branche.

Vous pouvez suivre ce schéma simple pour commencer:

1. Créez une copie de votre branche maître / tronc et appelez-la temp_master
2. Trouvez la branche avec la plus grande divergence de maître / tronc.
3. Déterminez si la branche doit être conservée, archivée ou supprimée.
   1. S'il doit être conservé, passez à l'étape 4.
   2. S'il doit être supprimé ou archivé, supprimez-le et archivez-le, puis revenez à l'étape 2.
4. Répétez l'étape 2 pour trouver la branche suivante avec le moins de divergence.
5. Fusionnez les deux branches trouvées à l'étape 2 et à l'étape 3, en résolvant tous les conflits.
6. Fusionnez vos deux branches dans votre temp_masterbranche.
7. Testez le code dans le code temp_master pour voir s'il se compile et se construit, et exécutez tous les autres tests automatisés que vous avez pour la santé mentale.
   1. Si des tests échouent, revenez en arrière, découvrez pourquoi, corrigez-les et répétez le processus.
   2. Si les tests échouent toujours, choisissez deux branches différentes avec lesquelles travailler.
8. Répétez les étapes 2 à 7 jusqu'à ce que vous n'ayez que deux branches, votre maître / tronc et temp_master.
9. Enfin, fusionnez temp_masteren maître / tronc et vivez avec votre nouveau modèle à branche unique.

Pour les grandes entreprises à cycle de 4 types semaines Git-Flow approche est préférée parce que vous obtenez bénéfice de la branche branche Feature production Master prêt est toujours déployable aussi, branche principale est propre de commits indésirables en suivant deux cycles commettras (de fonction pour Developet Developbranche maîtriser).

De plus, la ramification est également déterminée par la fréquence des mises en production. Pour un déploiement fréquent en production, il est préférable d'avoir une branche Feature ou un modèle centralisé. Dans ce cas, les frais généraux de gestion des succursales sont déplacés vers des tests robustes dans des environnements inférieurs pour maintenir la stabilité de la production.