Comment gérer les changesets de contrôle de source avec plusieurs changements de chevauchement et reconstructions quotidiennes?

Question

Je travaille dans une entreprise qui utilise cvs pour le contrôle de version.

Nous développons et maintenons un système en ligne impliquant une centaine d'exécutables - qui partagent de grandes quantités de code, et un grand nombre de fichiers de support.

Nous avons une branche de tête, et des branches vivantes prises de la branche de la tête. Les branches actives représentent les versions majeures publiées environ tous les trois mois. De plus, il existe de nombreux correctifs quotidiens de bogues qui doivent être appliqués à la branche live - de sorte qu'ils peuvent être immédiatement transférés dans l'environnement live, et fusionnés à la branche head, de sorte qu'ils seront dans le prochain Libération.

Notre difficulté la plus évidente est avec les correctifs quotidiens. Comme nous avons beaucoup de modifications quotidiennes, il y a toujours plusieurs changements dans l'environnement de test. Souvent, lorsque les exécutables sont reconstruits pour une tâche, les modifications non testées apportées au code partagé sont incluses dans la génération et transférées dans l'environnement en direct.

Il me semble que nous avons besoin d'outils pour mieux gérer les changesets.

Je ne suis pas la personne qui fait les builds, donc j'espère trouver un processus simple pour gérer cela, car il me sera plus facile de faire en sorte que le gestionnaire de construction s'intéresse à l'adopter.

Answer 1

Je pense que vous avez besoin d'un changement dans la disposition du référentiel. Si je comprends bien, votre dépôt ressemble à ceci:

Mainline 
| 
-- Live branch January (v 1.0) 
| 
-- Live branch April (v 2.0) 
| 
-- Live branch July (v 3.0) 

Ainsi, chacune des branches contient tous vos sites (des centaines), ainsi que des dossiers de code partagé.

Il n'y a aucun moyen scientifique de dire exactement le risque d'une erreur apparaissant après une libération, mais laisse jeter un oeil sur les deux facteurs les plus importants:

• Nombre de lignes de code commises par unité de temps . Vous ne pouvez pas/ne voudrez pas changer globalement cela car c'est la production de productivité du développeur.
• Couverture de test, alias à quelle fréquence le code est-il exécuté AVANT d'être en ligne et quelle partie de votre base de code est impliquée. Cela pourrait facilement être changé en donnant aux gens plus de temps pour tester avant une version ou en mettant en œuvre des tests automatisés. C'est un problème de ressources.

Si votre entreprise ne veut dépenser de l'argent sur des tests supplémentaires, ni la fréquence de sortie de diminution (non neccessarily de productivité!), Vous aurez en effet de trouver un moyen de libérer moins de changements, ce qui diminue effecively le nombre de lignes modifiées de code par Libération. En conséquence de cette idée, avoir tous les développeurs s'engageant dans la même branche et allant en direct plusieurs fois par jour ne semble pas être une bonne idée, n'est-ce pas?

Vous souhaitez augmenter l'isolation.

Isolation dans la plupart des systèmes de controll version est mis en œuvre par

1. numéros de révision Incrémentation par commettras atomique
2. Branching

Vous pouvez essayer de mettre en œuvre une solution qui emballe les changements de plusieurs révisions en version -packages un peu comme le système de contrôle de version "perforce" le fait. Je ne ferais pas cela même si la ramification est toujours la plus facile. Gardez le principe KISS à l'esprit.

Alors, comment les branchements peuvent-ils aider? Vous pouvez essayer d'isoler les changements qui doivent être mis en ligne aujourd'hui à partir de changements que pourrait mettre à mettre en ligne demain ou la semaine prochaine.

Iteration Branches

Mainline 
| 
-- Live branch July (v 3.0) 
    | 
    -- Monday (may result in releases 3.0.1 - 3.0.5) 
    | 
    -- Thuesday (may result in releases 3.0.6 - 3.0.8) 
    | 
    -- Wednesday (may result in releases 3.0.9 - 3.0.14) 

Les gens ont besoin de passer plus de réflexion sur le « ciblage » de leurs changements à la bonne version, mais il pourrait conduire à des changements pas si urgents (especialy le code partagé/bibliothèque) rester plus longtemps EN DEHORS d'un communiqué et à l'intérieur de la branche en direct où, par hasard ou par des tests systématiques, ils pourraient être découverts avant d'être mis en ligne (voir couverture des tests factoriels). Une fusion supplémentaire est nécessaire bien sûr et parfois cherrypicking des changements hors de la branche de vie dans la branche quotidienne.

Maintenant s'il vous plaît ne me prenez pas trop littéralement avec les branches quotidiennes. Dans mon entreprise, nous avons des itérations de 2 semaines et pour chaque itération une branche de publication et il y a suffisamment de frais généraux pour maintenir cette branche. Au lieu d'isoler le jour, vous pouvez essayer d'isoler par produit/site.

Branches du projet

Mainline 
    | 
    -- Live branch July (v 3.0) 
     | 
     -- Mysite-A (released when something in A changed and only released to the destination of A) 
     | 
     -- Mysite-B 
     | 
     -- Mysite-C 

Dans ce scénario le code du site unique et tout le code partagé nécessaire et les bibliothèques résideraient dans une telle branche du site. Si le code partagé doit être modifié pour que quelque chose fonctionne sur le site A, vous ne modifiez que le code partagé dans le site A. Vous fusionnez également la modification afin que tout le monde puisse suivre vos modifications. Les cycles de rattrapage peuvent être beaucoup plus longs que les versions, de sorte que le code a le temps de "mûrir". Dans votre processus de déploiement/construction, vous devez vous assurer que le code partagé du site A n'écrase PAS bien sûr les utilisations du site partagé B. Vous «effacez» efficacement votre code partagé avec toute implication (incompatibilité, surcharge pour l'intégration des changements d'équipe).

Une fois dans un certain temps, il devrait être forcé se fond jusqu'à la branche en direct (vous pouvez renommer ce alors trop) pour intégrer tous les changements qui ont été faites sur le code partagé. Votre itération de 3 mois vous forcera à le faire de toute façon, mais vous pourriez découvrir que 3 mois est trop long pour une intégration sans tracas.

La troisième approche est la plus extrême.

Projet & Iteration Branches

Mainline 
    | 
    -- Live branch July (v 3.0) 
     | 
     -- Mysite-A 
      | 
      -- Week 1 
      | 
      -- Week 2 
      | 
      -- Week 3 
     | 
     -- Mysite-B 
      | 
      -- Week 1 
      | 
      -- Week 2 
      | 
      -- Week 3 
     | 
     -- Mysite-C 
      | 
      -- Week 1 
      | 
      -- Week 2 
      | 
      -- Week 3 

Cela porte certainement un énorme ammount de maux de tête en tête et potentiel si vous ne faites pas attention. Sur le bon côté, vous pouvez très précisement déployer seulement les changements qui sont nécessaires maintenant pour CE Projet/Site.

J'espère que tout cela vous donne quelques idées.

Le contrôle de source appliqué est beaucoup sur le contrôle du risque pour une meilleure qualité du produit.

Bien que la décision quant au niveau de qualité que votre entreprise souhaite offrir ne soit pas entre vos mains, sachant qu'elle vous aidera à décider des changements à suggérer. Peut-être que vos clients sont satisfaits de votre qualité et que d'autres efforts pour l'augmenter ne sont pas amortis.

Bonne chance. Christoph