Continuez-vous le développement dans une branche ou dans le coffre?

Question

Supposons que vous développiez un logiciel avec des versions périodiques. Quelles sont les meilleures pratiques en matière de branchement et de fusion? Découper les branches de publication périodique auprès du public (ou de votre client), puis poursuivre le développement sur le tronc, ou considérer le tronc comme la version stable, l'étiqueter périodiquement et effectuer votre travail expérimental dans les succursales. Qu'est-ce que les gens pensent est le tronc considéré comme "or" ou considéré comme une "boîte de sable"?

Answer 1

J'ai essayé les deux méthodes avec une grande application commerciale.

La réponse à quelle méthode est la meilleure, dépend fortement de votre situation exacte, mais je vais écrire ce que l'ensemble de mon expérience a montré jusqu'à présent.

La meilleure méthode globale (dans mon expérience): Le tronc doit être toujours stable.

Voici quelques lignes directrices et les avantages de cette méthode:

• Le Code de chaque tâche (ou un ensemble de tâches) dans sa propre branche, alors vous avez la possibilité de quand vous voulez fusionner ces tâches et d'effectuer un communiqué.
• QA doit être effectuée sur chaque branche avant qu'il est sur le trunk.
• En faisant QA sur chaque branche, vous saurez exactement ce qui a causé le bug plus facile.
• Cette solution s'adapte au nombre de développeurs.
• Cette méthode fonctionne depuis la ramification est une quasi-instantanéité de l'opération dans le SVN.
• Étiquette de chaque version que vous effectuez.
• Vous pouvez développer des fonctionnalités que vous n'avez pas l'intention de sortir pendant un certain temps et de décider exactement quand les fusionner.
• Pour tous le travail que vous faites, vous pouvez avoir l'avantage de commettre votre code. Si vous travaillez hors du tronc seulement, vous aurez probablement garder votre code non validées beaucoup, et donc sans protection et sans détection automatique de l'histoire.

Si vous essayez de faire le contraire et de faire tout votre développement dans le coffre, vous aurez les questions suivantes:

• Constante des problèmes de génération pour les builds quotidiens
• La perte de productivité lorsqu'un développeur s'engage un problème pour toutes les autres personnes sur le projet
• Plus de cycles, parce que vous avez besoin pour obtenir enfin une version stable
• Moins les versions stables

Vous ne pourront tout simplement pas avoir la flexibilité dont vous avez besoin si vous essayez de garder une direction stable et le tronc que le développement de la sandbox. La raison en est que vous ne pouvez pas choisir et de choisir le tronc de ce que vous voulez mettre dans cette version stable. Il serait déjà tout mélangé ensemble dans le coffre.

Le seul cas particulier que je voudrais dire à faire tout le développement dans le coffre, c'est quand vous commencez un nouveau projet. Il peut y avoir d'autres cas trop en fonction de votre situation.

---

Par la façon distribuée systèmes de contrôle de version de fournir beaucoup plus de souplesse et je les recommande fortement de commutation soit hg ou git.

Answer 2

J'ai travaillé avec les deux techniques, et je dirais que le développement sur le tronc et les branches hors des points stables que les rejets est la meilleure façon d'aller.

Ces personnes ci-dessus qui s'opposent à dire que vous aurez:

• Constante des problèmes de génération pour les builds quotidiens
• La perte de productivité lorsqu'un développeur s'engage un problème pour tous les d'autres personnes sur le projet

avez probablement pas en continu utilisé des techniques d'intégration.

Il est vrai que si vous ne faites pas plusieurs versions de test au cours de la journée, par exemple une fois par heure, ou alors, va s'ouvrir à ces problèmes, qui va très vite asphyxier le rythme de développement.

Faire plusieurs versions de test au cours de la journée rapidement des plis dans les mises à jour de la base de code principale de sorte que d'autres peuvent l'utiliser et vous alerte également au cours de la journée si quelqu'un a brisé le construire de sorte qu'ils peuvent le réparer avant de rentrer à la maison.

Comme l'a souligné, seulement de trouver une fracture de construire lorsque la nightly build pour exécuter les tests de régression échoue est de la pure folie et va rapidement ralentir les choses.

Avoir une lecture de Martin Fowler papier sur l'Intégration Continue. Nous avons lancé notre propre système de ce type pour un projet d'envergure (plus de 3.000 kSLOC) environ 2 000 lignes de Posix sh.

Answer 3

J’ai tendance à adopter l’approche « branche de libération ». Le tronc est volatil. Une fois sortie des approches de temps, je voudrais faire une branche de libération, dont je voudrais traiter avec plus de prudence. Lorsque c’est enfin fait, je serait étiquette l’état du référentiel donc je voudrais savoir la version « officielle ».

Je comprends il existe d’autres façons de le faire - c’est juste la façon dont je l’ai fait dans le passé.

Answer 4

Les deux.

Le tronc est utilisé pour la majorité de développement. Mais on s'attend à ce que tous les efforts seront faits pour s'assurer que tout vérifier dans le coffre pour ne pas le casser. (partiellement vérifiée par un système automatisé et le système de test)

Les rejets sont maintenus dans leur propre répertoire, avec uniquement des corrections de bugs être fait sur eux (et ensuite fusionnées dans le tronc).

Toute nouvelle fonctionnalité qui va quitter le tronc de l'instabilité ou de la non-état de fonctionnement se fait dans sa propre branche distincte et ensuite fusionnées dans le tronc jusqu'à la fin.

Answer 5

J'aime utiliser l'approche décrite par Henrik Kniberg dans le Contrôle de Version pour Plusieurs Équipes Agiles. Henrik a fait un bon travail en expliquant comment gérer le contrôle de version dans un environnement agile avec plusieurs équipes (fonctionne pour une seule équipe dans des environnements traditionnels trop) et il n'y a pas de point à la paraphrase lui donc je vais juste poster le "cheat sheet" (ce qui est pour expliquer) ci-dessous:

Je l'aime parce que:

• C'est simple: vous pouvez obtenir à partir de l'image.
• Il fonctionne (et de l'ampleur) bien sans trop de fusion et de conflit d'ennuis.
• Vous pouvez libérer de travail "logiciel" à tout moment (dans l'esprit de l'agile).

Et juste au cas où il n'était pas assez explicite: le développement se fait dans la "branche de travail(es)", le tronc est utilisé pour le faire FAIRE (détachable) du code. Vérifiez le Contrôle de Version pour Plusieurs Équipes Agiles pour tous les détails.