Comment travailler simultanément sur la version 1.1 et la version 2.0 ?

Question

La situation:Nous n'avons plus de version bêta et la version 1.0 a été publiée sur plusieurs sites clients.L'équipe A est déjà occupée à travailler sur la version 1.1 qui comportera des corrections de bugs incrémentielles et des ajustements d'utilisabilité, tandis qu'une autre équipe travaille sur la version 2.0 avec des changements à grande échelle, où le cœur du produit a peut-être été complètement repensé.Désormais, la plupart des modifications apportées à la version 1.1 devront être intégrées à la version 2.0 à un moment donné, et certaines des corrections de bugs apportées dans la branche 2.0 devront peut-être en fait être planifiées pour une version antérieure.Le problème est que puisque la version 2.0 présente des différences fondamentales, aucune modification par rapport à la version 1.1 ne peut être fusionnée sans conversion manuelle, et vice versa.

Ma question:Quelles sont les meilleures pratiques de contrôle des révisions pour minimiser les conflits de fusion et les duplications de travail dans ce type de situation ?Comment puis-je m'assurer que mes équipes consacrent le moins de temps et d'efforts possible aux problèmes de contrôle des révisions, tout en fournissant régulièrement des correctifs aux clients ?

Answer 1

Un bon moyen consiste à corriger chaque bug dans la branche stable et à fusionner la branche stable dans la branche de développement.C'est le Lignes parallèles de maintenance/développement modèle, et la clé est de fusionner tôt et souvent.Une fusion rare et tardive signifie que la branche de développement est méconnaissable par rapport à la branche stable, ou que le bug ne peut pas être répété de la même manière.

Subversion inclut le suivi des fusions depuis la version 1.5 afin que vous puissiez vous assurer que le même ensemble de modifications n'est pas fusionné deux fois, provoquant des conflits stupides.D'autres systèmes existent (par ex. Git, Mercuriel, Précision, Forcément) Cela vous permettait de faire des requêtes du type "Quelles modifications sur la branche A n'ont pas été fusionnées dans la branche B?" Et cueillez cerise les correctifs dont vous avez besoin pour la branche de développement.

Answer 2

L'article ici (Au quotidien avec Subversion) mentionne qu'une méthode consiste à mettre constamment à jour la version 2 avec les données de la version 1.1.Dans l'article, le gars dit de faire ça tous les jours.

La partie que vous voudrez lire s'intitule « Serveur, il y a un bug dans mon coffre ! ».Nous sommes à peu près à la moitié de l'article.

Answer 3

Je m'appuierais probablement sur un système de suivi des problèmes à cette fin et m'assurerais de marquer chaque modification qui devait être apportée au code réseau.Vous pouvez ensuite vous assurer que les commentaires d'enregistrement pour chaque modification font référence au problème concerné et expriment clairement l'intention du changement de code afin qu'il puisse être facilement compris lors de la tentative de réimplémentation dans le tronc.

Answer 4

C'est à peu près ce que tout le monde a dit, mais j'ai pensé que j'ajouterais mon expérience dans la gestion du développement dans plusieurs branches à l'aide de SVN.

Avec notre produit principal, nous avons besoin de développer simultanément plus de 2 versions en même temps.

À l'origine, j'utilisais le tronc principal comme version de « développement principal », avec des balises utilisées pour chaque version réelle.Les branches ont été utilisées pour des efforts de développement substantiels pour un nouvel ensemble de fonctionnalités.Plus tard, lorsque nous avons commencé à travailler sur les versions 2, 3 et 4 à la fois, j'ai commencé à utiliser une branche pour chaque révision.

Étant donné que je gère le référentiel et que je gère également la diffusion des builds QA, je m'assure de faire des "rollups" chaque matin - ce qui consiste à fusionner les modifications dans l'arborescence en commençant par la branche actuellement active la plus basse.Je finis donc par fusionner les modifications de 1.1 en 1.2, qui sont fusionnées en 1.3 avec toutes les autres modifications de 1.2 depuis la dernière fusion, etc.

Lorsque je m'engage, je m'assure de toujours commenter le commit avec quelque chose comme

fusionné 1.1 rév 5656-5690

Cela peut être un peu pénible, mais ça marche :)

Answer 5

Fusionnez tôt, fusionnez souvent et assurez-vous que le contrôle qualité sur la ligne principale connaît et régresse/vérifie les défauts corrigés dans chaque correctif des versions de maintenance.

Il est très facile de laisser quelque chose s'échapper et de « corriger » un bug dans une version ultérieure, et laissez-moi vous dire que les clients ne se soucient pas de la complexité de la gestion de plusieurs succursales : c'est votre travail.

Assurez-vous que vous utilisez un système de contrôle de code source prenant en charge les branchements et la fusion (j'ai de l'expérience avec Perforce et SVN, et bien que Perforce soit meilleur, SVN est gratuit).

Je pense également que le fait d'avoir une seule personne chargée d'effectuer les fusions de manière cohérente permet de garantir qu'elles se produisent régulièrement.Il s'agissait généralement de moi ou d'un des cadres supérieurs de notre équipe.

Answer 6

La façon dont nous gérons cela dans mon travail est de conserver la branche tronc comme code le plus avancé (c'est-à-dire 2.0 dans ce cas).Vous créez une branche pour le code 1.x et y effectuez tous vos correctifs.Toute modification apportée à 1.x doit être fusionnée (manuellement, si nécessaire) dans la branche tronc (2.0).

J'insisterais alors pour que les développeurs 1.x notent à la fois le numéro de révision du commit 1.x et le numéro de révision de la fusion 2.0 dans le ticket pour ce bogue.De cette façon, il sera plus facile de remarquer si quelqu'un oublie de fusionner ses modifications, et le fait de devoir en garder une trace l'aidera à s'en souvenir.

Answer 7

Un point clé est capturé dans cette image de The Build Doctor :fusionner seulement une direction.

Answer 8

Pour répondre à cette question spécifique, de nombreux développeurs sont passés de Subversion à Git.Consultez github.com.