Devriez-vous vous soucier des succursales SVN si vous n'en avez jamais qu'une?


10

Si nous ne travaillons qu'avec une seule branche dans Subversion, devrions-nous même nous embêter? Ne pouvons-nous pas simplement travailler sur le coffre pour accélérer les choses?

Voici comment nous développons avec Subversion:

  • Il y a un coffre
  • Nous faisons une nouvelle branche de développement
  • Nous développons une nouvelle fonctionnalité sur cette branche
  • Lorsque la fonctionnalité est terminée, elle est fusionnée dans le tronc, la branche est supprimée et une nouvelle branche de développement est créée à partir du tronc

Lorsque nous voulons sortir en production, nous créons un tag à partir du tronc. Les corrections de bugs sont faites sur une branche à partir de cette balise. Ce correctif est ensuite fusionné dans le coffre.

C'est pourquoi nous créons une nouvelle branche de développement après qu'une fonctionnalité soit terminée. De cette façon, le correctif est inclus assez tôt dans notre nouveau code.

Voici un schéma qui devrait clarifier:

Notre stratégie Subversion

Maintenant, on a l'impression que ce n'est pas la façon la plus efficace de travailler. Nous construisons localement avant de nous engager, ce qui prend environ 5 à 10 minutes. Vous pouvez comprendre que cela est vécu comme un temps d'attente assez long.

L'idée d'une branche de développement est que le tronc est toujours prêt à être publié. Mais ce n'est plus vrai dans notre situation. Parfois, une fonctionnalité est presque prête, et certains développeurs commenceront déjà à coder la fonctionnalité suivante (sinon, ils attendraient qu'un ou deux développeurs finissent et fusionnent).

Ensuite, lorsque la fonctionnalité 1 est terminée, elle est fusionnée dans le tronc, mais avec quelques validations de la fonctionnalité 2 incluses.

Alors, devrions-nous même nous soucier de la branche de développement, car nous n'avons qu'une seule branche? J'ai lu sur le développement basé sur les troncs et la branche par abstraction, mais la plupart des articles que j'ai trouvés se concentrent sur la partie branche par abstraction. J'ai l'impression que c'est pour de gros changements qui s'étaleront sur plusieurs versions. Ce n'est pas un problème que nous rencontrons.

Qu'est-ce que tu penses? Pouvons-nous simplement travailler sur le coffre? Le pire scénario est (je pense) que nous devions créer une balise à partir du tronc et choisir les commits dont nous avons besoin, car certains commits / fonctionnalités ne sont pas encore prêts pour la production.


1
Je pense que ce serait mieux si vous aviez plus d'une succursale. Un pour chaque fonctionnalité. De cette façon, si vous commencez à travailler sur une grande fonctionnalité qui prendra un peu de temps, vous ne retarderez pas les corrections de bogues et autres pour les versions déjà publiées.
Amy Anuszewski

Une branche pour chaque fonctionnalité semble la rendre plus compliquée, alors que nous essayons de réduire la complexité. De plus, s'il y a un bug (c'est-à-dire pour 1.0), cela peut être fait sur une branche faite à partir de la balise. Ensuite, nous pouvons étiqueter cette branche (en faisant une 1.1), la libérer et fusionner le bugfix dans le tronc. Le développement de la grande fonctionnalité se poursuivrait sur le coffre.
Peter

Réponses:


6

IMHO travaillant directement sur le tronc est très bien si vous pouvez vous engager par petits incréments et que vous avez une intégration continue en place, de sorte que vous pouvez vous assurer (dans une mesure raisonnable) que vos validations ne cassent pas les fonctionnalités existantes. Nous le faisons aussi dans notre projet actuel (en fait, je n'ai travaillé sur aucun projet utilisant des branches spécifiques à une tâche par défaut).

Nous créons uniquement une branche avant la publication, ou si une fonctionnalité prend beaucoup de temps à implémenter (c'est-à-dire qu'elle couvre plusieurs itérations / versions). La taille approximative d'une tâche peut presque toujours être estimée suffisamment bien pour que nous sachions à l'avance si nous avons besoin d'une branche distincte pour celle-ci. Nous savons également combien de temps il reste avant la prochaine version (nous publions des versions tous les 2 mois environ), il est donc facile de voir si une tâche correspond ou non au temps disponible avant la prochaine version. En cas de doute, nous la reportons jusqu'à ce que la branche de publication soit créée, alors il est OK de commencer à travailler dessus sur le tronc. Jusqu'à présent, nous n'avions besoin de créer une branche spécifique à une tâche qu'une seule fois (dans environ 3 ans). Bien sûr, votre projet peut être différent.


1
Je suis avec Peter. Nous avons une branche pour chaque version prise en charge, mais sinon, nous travaillons en tronc. Nous utilisons également l'intégration continue, mais sachez que cela signifie uniquement qu'il compilera et non qu'il n'a pas rompu les fonctionnalités existantes, même avec des tests unitaires.
Ian

@Ian, bien sûr, aucun test ne peut garantir dans la vie réelle que le code est 100% sans bug ... avec des ressources limitées, nous visons un niveau de sécurité raisonnable (dont la définition est spécifique au domaine et au projet). Notez également que CI peut également exécuter des tests d'intégration, etc., pas seulement des tests unitaires.
Péter Török

Cela fonctionne jusqu'à ce qu'il échoue. Si vous avez besoin d'implémenter un correctif avant que la nouvelle fonctionnalité ne soit prête ... Ou si une nouvelle version de fonctionnalité n'était pas aussi prête pour les heures de grande écoute que vous pensiez qu'il devient beaucoup plus difficile de sauvegarder ce changement hors du code si vous n'utilisez pas de branchement.
SoylentGray

@Chad, les correctifs de la dernière version sont effectués sur la branche de publication correspondante, sans interférence du tronc. Et nous testons les nouvelles fonctionnalités assez largement afin de savoir quand elles sont prêtes pour les heures de grande écoute. Certes, nous avons relativement peu de grandes fonctionnalités dans notre projet. Et comme il s'agit d'une application Web côté serveur, il est assez facile même d'ajouter un indicateur de base de données pour activer / désactiver sélectivement les fonctionnalités. YMMV.
Péter Török

LOL ok j'ai mal compris et je pensais que vous veniez d'avoir le coffre (à une exception près). ) entiers.
SoylentGray

1

Ce que vous décrivez avec votre développement de fonctionnalités est un développement parallèle (développement simultané ciblant différentes versions de produits) et il nécessite des branches pour le gérer correctement. Vous pouvez avoir une branche pour chaque version ou pour chaque fonctionnalité si vous devez souvent recomposer les fonctionnalités qui feront une version particulière.

L'autre façon de le faire serait de travailler à partir du tronc par défaut mais de créer une branche si vous vous attendez à ce que votre tâche s'étende au-delà de la prochaine version. Vous marquez toujours la version bien sûr.

L'approche que vous adoptez dépend vraiment de la quantité de gestion que vous pouvez faire à l'avance. Si la version typique n'a pas vraiment de développement parallèle, je prendrais la deuxième approche.


Je suis d'accord et OP l'a confirmé avec: `` Parfois, une fonctionnalité est presque prête, et certains développeurs commenceront déjà à coder la prochaine fonctionnalité ... ''
Chris

Oui, mais nous n'avons jamais à recomposer. Les fonctionnalités sont implémentées de manière chronologique et, par exemple, les fonctionnalités 1 à 4 doivent toutes figurer dans la prochaine version (disons 1.0). La seule fois où cela pourrait être problématique, c'est lorsque le développement a commencé sur la fonctionnalité 5, qui est pour la version ultérieure (2.0). Ensuite, nous devons nous assurer que ces modifications ne sont pas prises en compte dans la balise / version (1.0). Faire une branche avant la sortie pourrait en effet résoudre ce problème.
Peter
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.