J'essaie de décider de la meilleure stratégie de ramification d'un projet d'application Web. Voici ce que j'ai monté jusqu'à maintenant et j'apprécierais énormément de commentaires et d'expériences.
La façon dont je le vois, il existe deux stratégies de ramification principales: "Branche par publication" et "Branche par caractéristique".
Maintenant, la façon dont je vois la grande différence pratique entre ces deux stratégies est que "par version" vous permet de maintane différentes versions de production de votre logiciel (lorsque le client A a la version 1 et le client B version 1.5, le client est le paiement payant. client dans ce cas). En revanche, en utilisant la stratégie "Par caractéristique", vous ne pouvez prendre en charge que la version de production actuelle (tous les clients utilisent la dernière version).
car dans une application Web typique Tous les clients utilisent la même version "la plus récente" (car elles accèdent tous le même serveur), je suppose que l'approche "par caractéristique" est la plus courante utilisé. Il supprime la nécessité de fusionner "à travers la hiérarchie", disons quand un bugfix doit être appliqué aux 3 versions de version.
Donc, mon statut actuel est que je devrais aller avec "Branche par fonctionnalité". Si cela importe, mon équipe n'est pas très qualifiée.
5 Réponses :
Si vous n'avez qu'une seule version en direct à tout moment et que vous développez tout le développement dans une seule branche de fonctionnalité, ces approches sont effectivement les mêmes.
Si une fonctionnalité de branche à vous signifie avoir plusieurs branches à la fois, je l'éviterais comme la peste. Plus de branches signifie plus de fusion, ce qui est une douleur en soi, et plus d'enfer d'intégration. Il est de loin préférable de faire une intégration continue à une seule codine.
Si votre processus de déploiement est plus impliqué que la succursale, le test, passer en direct, un avantage de la libération de la branche est que vous pouvez avoir plusieurs branches de libération allant à la fois, dans différentes phases: une en direct et d'être bug6 nécessaire, et une autre étant stabilisée, testée, passant par l'acceptation, etc., tandis que le développement continue sur le tronc. Si vous avez un coffre en direct, d'autre part, une fois que vous fusionnez une branche de fonctionnalité dans la vue de la prise en direct, vous avez perdu votre capacité à faire des bugs au système en direct actuel. La branche Feature Fusion devient un point de non retour.
Je n'ai pas pensé à cela comme ça avant, point de vue intéressant 1+ de moi :-)
Hmm .. Vous mentionnez "Fusionner une fonctionnalité avec une vue pour le prendre en direct ". Dans un tel cas, ont un problème car, comme vous l'avez dit, vous venez de perdre la capacité de faire des bugs sur le système en direct. Mais pour moi fusionnez une fonctionnalité signifie: la fusion des fonctionnalités et la libération d'une nouvelle version est une opération atomique. En d'autres termes, la fusion d'une nouvelle fonctionnalité signifie que directement après la fusion, le coffre va vivre comme nouvelle version. Cela implique également que le client a testé et accepté la nouvelle fonctionnalité avant la fusion. Mais maintenant que je lis mon commentaire, il contient une sorte de bizarre ...
@Bernardmarx: Je pense que vous avez trouvé le problème: vous ne pouvez pas tester le code qui ira vivre jusqu'à ce que vous ayez fusionné, car cela n'existe pas jusqu'à présent. Mais une fois que vous avez fusionné, vous êtes commis. Je suppose qu'il y a une fenêtre étroite: vous pourriez geler le coffre, faire la fusion sur une machine de développement, exécuter une QA de pré-production sans vérifier , puis commettre la fusion si elle passe, prenant le code engagé. Vivre tout de suite. Si vous aviez désespérément besoin de bugfix en direct pendant cette époque, vous pouvez dégeler le coffre, fixer, puis commencer la fonctionnalité de la fusion de nouveau. Ne pense pas que je voudrais essayer cela!
La fusion n'est pas une douleur avec Git ou Mercurial, j'entends.
@Ziplin: de meilleurs outils - comme Git et Mercurial - couper une partie de la complexité réductible de la fusion. Mais il y a encore une complexité irréductible - le fait que votre code sur ici sait comment traiter les cartes de crédit et PayPal, mais le code que vous fusionnez sur là permet maintenant aux clients Payer avec des cartes-cadeaux. Aucun outil ne peut aider avec ça. La fusion plus tôt et la plus souvent peut, parce que cela vous permet de gérer la divergence alors qu'elle est encore petite.
@Tom Anderson: Yeah gelant le coffre peu de temps avant que je pensais que je pensais et je suis d'accord que cela ne sonne tout simplement pas élégant.
J'ai tendance à utiliser Git pour mes projets, mais le processus que j'ai tendance à suivre va comme ça (et devrait fonctionner aussi pour Subversion):
Production_Release_22 ou production_release_new_feature_x , puis déployez cette balise sur le serveur de production.
Les balises sont jamais , jamais mises à jour - une fois que quelque chose est déployé, il reste de cette façon jusqu'à ce que de plus de modifications soient construites, testées et étiquetées - et puis la nouvelle étiquette est déployé. En veillant à ce que ce soit tags se faire déployer et non succursales , je me tiens à moi (ou à d'autres) de faire des choses comme "Je vais simplement valider celui-ci rapide changer et mettre à jour le serveur sans le tester ".
C'est bien fonctionné pour moi jusqu'à présent.
Je ne comprends pas vraiment quelle est votre branche de rassemblement. Pour moi, cela ressemble à une branche de fonctionnalité avec le coffre qui a été fusionné. Donc, fondamentalement la même chose qu'une branche de fonctionnalité qui est tenu à jour avec le coffre. Je discute probablement la sémantique ici ...
La branche de la mise en scène est l'endroit où toutes les choses qui sont finies (mais pas nécessairement complètement testées / confirmées par le client) Go - le serveur de stockage exécute le code éteint de la branche de stadification, mais le serveur de production ne fonctionne que des étiquettes de la branche de production (qui La mise en scène est fusionnée lorsque nous confirmons qu'il est temps de déployer les changements).
Si vous avez appelé la branche de mise en scène «Trunk» et la branche de production 'Libération », est-ce essentiellement la même chose que la stratégie de branche par caractéristique et de libération que d'autres suggèrent également? Ou y a-t-il des différences subtiles?
Fondamentalement la même chose, oui - je dirais que la seule différence majeure consiste à utiliser des étiquettes au lieu de branches pour les déploiements de production.
ces choix ne sont pas mutuellement exclusifs - utilisez les deux. ils résolvent différents problèmes:
J'utiliserais les deux, mais vous pouvez renoncer à l'une des approches si le problème que la résolution ne s'applique pas à vous ou si vous avez une solution différente de problème.
Je recommande vivement d'utiliser un DVC moderne comme Git ou Mercurial. Ils sont axés sur le développement parallèle, ils stockent donc des changements différemment des systèmes plus anciens, ce qui fait la fusion beaucoup de Saner.
au risque de vous déranger davantage: vous pouvez avoir la libération des succursales Cela étant dit, on dirait que vous n'avez pas besoin de familles de libération parallèles et que vous souhaitez déployer souvent, peut-être même continu . Vous voudrez donc avoir un "coffre stable" que vous pouvez libérer à tout moment. Les branches de fonctionnalités aident à garder le tronc stable, car vous ne fusionnez que dans le coffre lorsque les modifications sont effectuées et se sont révélées elles-mêmes.
Donc, je dirais que votre choix est un bon ajustement.
Une approche du déploiement continu consiste à développer des fonctionnalités sur les succursales et à fusionner uniquement au coffre lorsqu'ils sont prêts à partir en direct. Qui conserve l'ajout d'éléments atomiques - ils sont absents ou complètes - mais cela signifie que vous avez des fantasmes importants et peu fréquents. Un autre est d'intégrer continuellement, mais de cacher des caractéristiques jusqu'à ce qu'ils soient prêts à partir en direct, avec une sorte d'interrupteur de configuration qui vous permet d'exposer dans des environnements internes. Cela signifie une intégration plus douce, mais est un peu d'un corps et complique les tests, car vous devez tester les modes de fonctionnalités et de fonctionnalités.
Bien que vous souhaitiez peut-être effectuer les fonctions en cours optionnelles - une approche Google Labs. Peut-être.
Quoi qu'il en soit (et désolé d'avoir fait trois commentaires), j'ai l'impression que les gars de déploiement continus sont fortement favorables à une seule codine avec une intégration continue (cela sort du modèle de fabrication maigre qui est l'origine intellectuelle de ce mouvement) et Je pense que leur approche est que les caractéristiques doivent être développées de manière incrémentielle. Je ne suis en aucun cas un expert sur une sorte de maigre, cependant, j'aimerais en savoir plus sur cette question particulière.
@TOM: Vous n'avez pas à reporter l'ensemble de la fusion - vous pouvez régulièrement fusionner les modifications du coffre à la branche de fonctionnalité pour rester synchronisée pendant que vous développez, de sorte que la réintégration à la fin soit triviale. Bien sûr, si les changements entrant dans le tronc sont volumineux, même ces fonts peuvent être une douleur. Il n'y a pas vraiment de solution pour cela autre que de fractionnement de gros changements dans des modifications importantes plus importantes.
Vrai, cela aide à garder les fonts plus petits. Néanmoins, si vous ne fusionnez que une branche de fonctionnalité dans le coffre lorsque la fonctionnalité est terminée, les modifications qui sortent du coffre sur les branches de fonctionnalités seront nécessairement caractéristiques. Que ce soit douloureux ou tout dépend de la taille des caractéristiques, je suppose.
Quel type de logiciel développez-vous? Emballage rétrécissant? Projet open source? Si oui, allez ensuite avec la "branche par libération" ou "tronc instable". Surtout si vos cycles de libération sont tous de six mois à une année à part.
Mais si vous avez le maintien d'un projet Web qui a des changements sur des fréquences plus courtes, comme une fois toutes les semaines ou moins, puis accédez à la "branche par caractéristique" ou à une approche "ligne stable". Le problème avec cette approche est l'intégration de multiples modifications de fonctionnalités qui ont des changements balayants rendent le processus de fusion moins que le plaisir. Cela devient vraiment difficile.
Mais ces deux fonctionnent bien, mais si vous avez besoin des deux? C'est-à-dire que vous avez un projet qui déploie une fois toutes deux semaines avec de gros changements de fonctionnalités, mais vous constatez que vous avez un certain nombre de corrections de bogues que vous ne pouvez pas attendre pour que ces modifications soient prêtes à être prêtes. Le coffre est votre branche de sortie avec l'approche "Branche par caractéristique". Et si vous pouviez obtenir les deux versions et comporte sa propre branche?
Déconnectez ce Entrée de blog par Collabnet's Bob Archer. Sa stratégie de libération agile vous donne le meilleur des deux. J'ai utilisé ceci. C'est extrêmement flexible. Même si Bob ne le montre pas dans son diagramme, vous pouvez avoir plusieurs branches de libération en même temps. Cela signifie que vous pourriez avoir une branche de libération qui est prête à être déployée à la production, et une autre en préparation pour les chèques de QA finales. Mais deux choses à considérer:
Tout d'abord, quelle est la fusion de vos développeurs? Vous ne pouvez pas faire l'approche stratégie de libération agile par vous-même, même si c'est une petite équipe. Tout le monde doit faire leur part et ils doivent vraiment comprendre la fusion et les outils qu'ils utilisent pour faire la fusion.
Deuxièmement, vous aurez besoin d'une bonne compréhension sur les changements prêts et ceux qui sont sur le point d'être. La gestion de la libération est la clé pour faire de ce travail comme des travaux d'horloge. Chaque fonctionnalité est prête à être assignée à une succursale de libération et à fusionner.
Cette stratégie de «libération agile» (qui s'oppose de manière diamétrique à la stratégie de libération du développement agile, mais peu importe) semble que cela implique une quantité d'arrosage oculaire de fusion. Quelle est la fréquence des fonts dans les branches de libération? Si tous les quelques jours, cela fonctionne tout à fait comme un tronc instable, mais où le rôle du tronc passe entre différentes branches au fil du temps. Cela devrait fonctionner et être plus flexible qu'un tronc stable. Mais si les fondues sont éloignées, je ne peux tout simplement pas voir ce travail - si un refactoring à grande échelle est effectué sur deux branches de tâches ou plus, vous obtenez un enfer de sept cercle fusion.
@Tom Anderson: la fusion des succursales de libération ne se produisent que lorsque la fonctionnalité est terminée. Donc, idéalement, il ne devrait y avoir qu'une fusion de la branche de fonctionnalité à la branche de la libération. Maintenant, cela dit, tous les problèmes ne sont pas élaborés dans une branche de fonctionnalité la première fois. Il peut donc y avoir des fonts ultérieurs à partir de la branche de fonctionnalité à la branche de déverrouillage pour les correctifs de correctifs s'il est mieux résolu dans la branche de fonctionnalité plutôt que la branche de déverrouillage.
@Tom Anderson: Vous êtes correct. Si des fondues sont éloignées (plus de quelques semaines) pour une libération, vous pourriez également réduire la fusion des frais généraux et utiliser une succursale par libération ou par branche par approche de fonctionnalités.
THX pour faire de la perspective des compétences. J'ai édité le message original pour indiquer que les compétences sont ... limitée
Merci d'avoir posé cette question - j'apprécie vraiment les réponses de chacun.