Présentation d'une stratégie de branchement de contrôle de version à une petite équipe


17

Je suis un entrepreneur qui a récemment commencé avec une entreprise.

L'équipe est composée de 3 développeurs composés de 2 développeurs de niveau junior à moyen, avec un autre au même niveau qui commence bientôt, et moi-même (6 ans xp). Pour les développeurs existants, il s'agit de leur premier emploi hors de l'université / du collège, et ils n'ont jamais eu de développeur senior supervisant leur travail auparavant.

Il n'y a pas de politique de contrôle de version explicite. Les développeurs effectuent tout le développement sur le tronc puis se déploient en production directement à partir de leurs machines de développement. L'équipe existante n'est pas familière avec la création de succursales.

Je change tout cela et présente CI, les serveurs de test / transfert / production TDD, etc., ainsi qu'une politique de contrôle de version pour compléter cela.

Le système de contrôle des sources est TFS, que je n'ai jamais utilisé auparavant. Il est configuré comme un référentiel géant.

J'ai écrit quelques conseils pour eux, mais y a-t-il autre chose que je devrais ajouter / modifier, compte tenu de l'expérience de l'équipe?

Politique de contrôle de version

Le développement se fait sur le tronc

Si un changement est estimé à prendre plus d'une semaine, il doit être effectué sur une branche, avec des fusions régulières du tronc dans la branche pour empêcher les deux de se désynchroniser.

Libérer les branches créées pour le code de production. Cette branche ne doit contenir que du code stable. Nous pouvons soit avoir une branche de publication qui est mise à jour à partir du tronc une fois par sprint, soit créer une branche de publication distincte pour chaque semaine.

Si un correctif de bogue urgent affectant le code de production doit être effectué, il est effectué sur la branche de publication et fusionné dans le tronc.

Si nous adoptons la stratégie d'une branche de publication, le tronc est fusionné dans la branche de publication une fois par sprint vers la fin du sprint.

Si nous adoptons la branche distincte par stratégie de version, le tronc ne sera JAMAIS fusionné dans la branche Release

Dans certains scénarios, il peut être nécessaire de corriger le bogue deux fois sur différentes branches, si les branches ont trop divergé. Si nous faisons des sprints courts, cela ne devrait pas arriver trop souvent.


J'ai l'intention d'avoir trois serveurs. Environnement de test qui exécute toujours le dernier code dans le référentiel. Un environnement de mise en attente qui exécute la dernière version candidate pour la mise en place / le test du code de la version candidate et à des fins d'UAT, et l'environnement de production.

La raison pour laquelle je prévois de le faire est que jusqu'à présent, le client n'a fait que des logiciels internes. Le projet le plus récent concerne un client médiatique de haut niveau et j'ai le sentiment que l'équipe doit adopter un modèle de développement plus professionnel que ce qu'elle fait actuellement.

Par exemple, pour le moment, un utilisateur peut téléphoner à l'équipe avec un rapport de bogue. Les développeurs localisent et corrigent le bogue, effectuent un test rapide du globe oculaire sur leurs propres machines, puis se déploient directement en production. Aucun test automatisé ou quoi que ce soit.


Avec le recul, je pense que la branche de fonctionnalité est un pas trop loin et je vais supprimer cela.

Donc, essentiellement, cela revient à a) pas de branchement du tout) b) une branche de libération et le tronc, et c) une branche de libération par libération et le tronc.

Je me penchais vers ce dernier. Ma pensée initiale serait que j'aurais à la fois une version candidate et une version à vivre sur des serveurs distincts (UAT / Production) en même temps, mais en fait, le tronc est la version candidate à tout moment, donc une branche par la libération penche vers la folie. Ma seule pensée serait que si nous ne voulions pas que nos parties prenantes voient le code de développement, nous pourrions avoir besoin d'une branche de candidat de version distincte, mais YAGNI et tout cela .....


3
avez-vous envisagé d'ajouter une explication de la raison pour laquelle vous avez choisi cette méthode? disons, de la même manière que cela se fait ici . Avez-vous également vérifié «Microsoft Team Foundation Server Branching Guidance» (référencé par exemple ici )?
gnat

3
Essayez celui-ci
gbjbaanb

1
Gardez à l'esprit que j'utilise TFS et non un DVCS comme GIT. Cela semble un peu spécifique.
MrBliz

2
La fin de ce lien indique: "Tout le monde travaille hors du tronc. Branche lorsque vous publiez du code. Branche une version lorsque vous devez créer un correctif de bogue pour le code déjà publié. Branche pour les prototypes." Je dirais que pour un début simple, vous étiquetez simplement les versions lorsque vous êtes raisonnablement sûr qu'elles sont terminées. À moins que plusieurs développeurs travaillent sur plusieurs fonctionnalités, il n'est pas nécessaire d'avoir plus d'une branche. Tout le monde ajoute des fonctionnalités, tout le monde corrige la version candidate, tout le monde est d'accord quand il est prêt à marquer. Cela signifie que vous n'avez qu'à remettre les branches pour les corrections de bugs plus tard.
TafT

1
Je suis mal à l'aise de mettre cela comme une réponse, car elle est trop basée sur l'opinion, mais j'ai eu beaucoup de succès à convaincre les gens d'utiliser une balise "last good good" (LKG), qui est une balise mobile sur le tronc identifiant la dernière "bénie" "version (CCB, test, etc.). Les développeurs sont informés que les versions seront effectuées à partir de cette balise LKG, pas de la tête du tronc, et au-delà, ils sont libres d'utiliser toutes les approches qui leur conviennent à l'époque. J'ai trouvé que ce modèle générait spontanément des branches de fonctionnalités lorsque le moment était venu, sans aucun effort initial ou travail supplémentaire sur les parties des développeurs.
Cort Ammon - Rétablir Monica

Réponses:


16

Pour une équipe de 3-4 développeurs, vous proposez bien trop de branches.

Chaque branche que vous créez est une surcharge supplémentaire qui a un coût (temps passé à fusionner, garder une trace de ce qui se trouve, etc.). Vous devez vous assurer que l'avantage que vous obtenez d'avoir une succursale l'emporte sur le coût.

Gardez à l'esprit que le seul véritable avantage pour une branche est l'isolation de code. Cela signifie que vous avez besoin d'une raison concrète pour vouloir isoler le code.

Avoir une branche de publication distincte pour chaque sprint est fou. Pourquoi avez-vous besoin du code d'un sprint isolé du code du suivant? Pourquoi ne pas simplement avoir une seule branche de publication stable qui sera reportée à chaque sprint?

Si un changement est estimé à prendre plus d'une semaine, il doit être effectué sur une branche, avec des fusions régulières du tronc dans la branche pour empêcher les deux de se désynchroniser.

Presque toute nouvelle fonctionnalité non triviale prendra au moins une semaine en temps réel après la prise en compte du développement, des tests des développeurs, des interruptions quotidiennes et d'autres activités, etc.

De plus, qu'est-ce qu'une "fusion régulière"? Du quotidien? Hebdomadaire? Chaque fusion que vous effectuez prend du temps - vous devez vous assurer que la branche de fusion cible se construit et s'exécute après vos modifications. Dans une petite équipe, les fusions fréquentes représentent beaucoup de frais généraux.

Nous avons une équipe de 4 développeurs travaillant sur une base de code de plus d'un million de lignes et voici comment nous opérons:

  • Branche principale où tout le développement est fait
  • Une branche par version majeure (effectuée environ une fois par an)

La seule règle majeure est: ne pas archiver le code qui ne se construit pas.

C'est ça. Simple, facile à comprendre, obtient l'isolement dont nous avons besoin (à tout moment, nous pouvons créer une version pour n'importe quelle version).

Les avantages d'avoir tout le travail de développement effectué sur une seule branche:

  1. Les développeurs sont toujours synchronisés entre eux. Aucune fusion douloureuse, car deux développeurs ont été sur leurs propres branches pendant des semaines, créant des changements incompatibles.
  2. Les versions cassées sont trouvées le même jour. Nous avons une version nocturne qui exécute le dernier code sur main. Si quelqu'un enregistre du code qui ne se construit pas pour une raison quelconque, nous le saurons immédiatement.
  3. Avec tout le monde travaillant toujours sur le même code, cela augmente les chances de trouver un bogue le plus tôt possible.
  4. Aucune surcharge de fusion autre que des correctifs ciblés pour libérer des branches. Dans une petite équipe, c'est la grande.

10
"Gardez à l'esprit que le seul véritable avantage pour une branche est l'isolement du code. Cela signifie que vous avez besoin d'une raison concrète pour vouloir isoler le code." - Et la révision du code? Je pense que c'est une bonne raison, même avec seulement deux développeurs.
BlueRaja - Danny Pflughoeft

2
La révision du code et la ramification ne sont pas vraiment liées. Êtes-vous en train de dire que vous ne voulez pas que le code soit archivé dans une branche particulière avant qu'il ne soit examiné?
17 de 26

5
@ 17of26, oui. La révision du code est généralement utilisée comme condition préalable pour être sur la ligne principale. Vous devez donc afficher le code d'une certaine manière avant cela: sur votre moniteur, dans un e-mail ou - dans de nombreuses configurations - sur une branche. Cela fonctionne mieux avec un outil de gestion de référentiel comme GitHub ou gerrit.
Paul Draper

3
TFS prend en charge les révisions de code via des étagères, qui sont des zones de stockage temporaires dans le contrôle des sources. Le code peut y vivre jusqu'à ce qu'il soit examiné puis enregistré.
17 du 26

2
Je suppose que le fait est que les branches ne sont pas vraiment le bon mécanisme à utiliser pour faire des revues de code.
17 de 26

31

Vous leur avez écrit quelques conseils, mais vous n'avez pas expliqué pourquoi votre approche est meilleure que celle qu'ils utilisent déjà . Cela peut être problématique. Si vous êtes dans un esprit "Nous le ferons à ma façon, parce que j'ai six ans d'expérience professionnelle, et vous pas" (et en lisant votre question, ça ressemble exactement à ça), soyez prêt à être détesté par les membres de votre équipe qui essaieront de faire tout ce qu'ils peuvent pour ne pas appliquer vos concepts.

Ont-ils un problème qui doit être résolu?Il est essentiel de répondre à cette question en premier, car soit ils ont réellement un problème et accueilleront vos suggestions, soit ils fonctionnent parfaitement bien comme ils le font actuellement, et vous leur faites simplement pression sur votre façon de travailler , simplement parce que vous préférez travailler de cette façon.

Finalement, les forcer à utiliser des succursales peut avoir un impact extrêmement négatif . Travailler avec un tronc est facile, surtout dans un environnement Agile. Un développeur valide les modifications du tronc, gérant éventuellement de petits conflits, et ces modifications sont immédiatement utilisées par la plate-forme d'intégration continue. Avec des succursales:

  • Un développeur doit réfléchir à l'emplacement du changement,

  • Quelqu'un doit gérer les branches et fusionner des branches au tronc,

  • Les fusions entre branches sont effectuées moins fréquemment que les validations, ce qui signifie que quelqu'un doit gérer des conflits plus importants et plus difficiles à gérer qu'un conflit entre deux validations,

  • Chaque commit ne trouve pas nécessairement son chemin dans l'intégration continue, ce qui retarde les informations que les développeurs obtiennent sur les effets qu'un commit peut avoir (en particulier les régressions).

Le fait que:

L'équipe existante n'est pas familière avec la création de succursales

aggrave encore les choses. J'ai travaillé dans une équipe de programmeurs inexpérimentés, où un manager inexpérimenté a décidé de jouer avec les branches. Cela a entraîné beaucoup ( beaucoup ) de perte de temps et c'est exactement ce que vous voulez éviter pour un projet qui a des délais.


3
Eh bien, dans ce modèle, comment allez-vous empêcher le code instable de passer à la production sans branchement?
MrBliz

2
@MrBliz: via des commutateurs. Vous pouvez activer une fonctionnalité pour les développeurs, mais la désactiver pour les utilisateurs finaux si elle n'est pas prête pour RTM.
Arseni Mourzenko

3
Compte tenu de l'expérience des développeurs avec lesquels je travaille et du manque actuel de tests automatisés, je ne pense pas que ce serait une bonne idée pour notre situation.
MrBliz

4
@MrBliz vous empêchez le code instable de passer en production en l'isolant dans les branches de publication (c'est exactement leur but) et en le testant . Les branches de fonctionnalité n'y aident pas; en fait, ceux-ci comportent un risque plus élevé d'instabilité lors de fusions importantes, non intégrées et difficiles à contrôler
GNAT

1
@MrBliz ouais je l'ai remarqué (et je pense que vous avez tout à fait raison, ne serait-ce que pour expliquer le raisonnement à l'appui de cela). C'est juste que ni votre commentaire ni cette réponse ne mentionnent explicitement s'il s'agit de versions ou de branches de fonctionnalités (ou les deux?), Alors j'ai commenté pour souligner la différence . FWIW étant vague à ce sujet est probablement la seule chose que je n'aime pas dans cette réponse
moucher

3

Comme le dit Mainma, soyez prudent avec la ramification. Vous parlez de succursales toutes les quelques semaines, est-il vraiment nécessaire d'avoir beaucoup de succursales?

Alternativement, vous pouvez également avoir un modèle «pull» au lieu d'un modèle push. Si vous utilisiez Git ou Mercurial, vous pourriez demander à un serveur d'intégration de valider leurs modifications avant de les envoyer au serveur central. Dans TFS, vous pouvez faire quelque chose de similaire en utilisant des archivages fermés . De cette façon, vous pouvez avoir la validation et éviter la complexité des branches.


En effet, il n'y aurait que trois branches actives (release, release release et trunk) à la fois, et la plupart du temps uniquement la branche release et trunk.
MrBliz

Les anciennes branches seront supprimées dans TFS, ou plus précisément masquées.
MrBliz
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.