Meilleures pratiques pour le contrôle de source et les corrections de bugs

Question

Si nous devons émettre un correctif de bogue n'incluant pas les développements en cours validés ni les modifications apportées à leur version actuelle, que faut-il faire pour rendre le processus plus sûr et avec moins de temps système?

Nous utilisons actuellement Subversion pour notre contrôle de code source dans une petite équipe (3 développeurs) développée principalement dans Visual Studio 2008. Nous prévoyons que l'équipe pourra regrouper jusqu'à 8 développeurs au cours de la prochaine année et que le support des versions précédentes deviendra plus compliqué. Bien que la plupart des clients utilisent la version actuelle, certains sont plus en retard.

Answer 1

Le contrôle de source peut gérer cela assez facilement et a été conçu pour cela.

Lorsque vous atteignez la période de stabilisation de votre publication, une branche doit être créée. Il est important que vous ne commenciez aucun travail sur la prochaine version avant que cela soit fait.

Toute correction de bogue pour cette version doit être effectuée dans cette branche. Cela empêche le nouveau code d'une prochaine version de polluer le correctif. Une fois la correction du bogue effectuée, vous pouvez fusionner cette modification avec le tronc et toute autre version, si nécessaire.

N'oubliez pas de mettre le numéro du bogue dans le commentaire, cela facilitera le suivi des commits.

Answer 2

Que diriez-vous: une branche par version majeure, avec des corrections de bugs appliquées à la (aux) branche (s) en fonction des besoins, et également appliquées (ou fusionnées) au tronc.

Answer 3

Là où je travaille, plusieurs projets fonctionnent simultanément. Afin d'éviter ce problème, nous avons plusieurs variantes du code source. Par exemple, la première version est la variante 1.0. Nous créons une branche de cette version, par exemple Variant 2.0, pour tous les développements futurs. Si nous avons besoin de corriger un bogue, nous le faisons sur la variante principale, qui est actuellement la 1.0 et peut la publier. Lorsque la variante 2.0 est prête à entrer en production, nous la fusionnons avec ce qui se trouve sur la branche principale (dans ce cas, 1.1) et cela devient le nouveau tronc principal. À un moment donné, nous avions 4 branches en même temps.

La fusion du code peut prendre beaucoup de temps et vous devez veiller à ne pas introduire de nouveaux bogues lors de la fusion, mais si vous disposez d'un outil de comparaison de code décent, il ne devrait pas être trop grave. Nous avons déjà fusionné en utilisant Beyond Compare sur un répertoire source de 10 000 fichiers, et cela a pris un seul matin.