Je travaille sur la migration de notre équipe de Dev vers Subversion et d'améliorer notre structure et nos processus de référentiel. Nous allons essentiellement avec la configuration standard du tronc / des branches / balises. J'avais à l'origine envisagé d'utiliser une stratégie de succursales (succursales / 1.0, succursales / 2.0, etc.), mais je suis maintenant penchée vers un modèle de promotion de code (branches de test et de production). C'est un peu mieux et plus intuitif pour la façon dont notre équipe fonctionne, mais des versions seront un peu moins simples: nous avons effectivement besoin de la branche de test pour devenir la branche de production. (La branche de production est toujours disponible pour les versions de maintenance, mais la branche de test n'a pas besoin d'exister entre le déploiement d'une libération et de l'essai de la suivante.)
Quelqu'un qui utilise la promotion du code peut-il recommander le meilleur moyen de mettre en œuvre une succursale à partir d'un test à la production? Je pense que ces options sont mes options, mais ne savez pas s'ils ont des avantages majeurs / contre:
a. Fusionner complètement la branche de test dans la branche de production, supprimer une branche de test
b. Supprimer la branche de production, test de copie à la production, supprimer une branche de test
c. Supprimer la branche de production, renommer la branche de test à la production
Merci pour tout conseil!
6 Réponses :
J'ai toujours pensé à des branches aussi courtes, et toutes mes sorties sont en fait dans le dossier Tags. Lorsque des correctifs sont nécessaires à une certaine version, la balise est copiée sur une branche, le travail est effectué et une nouvelle étiquette est créée. Je suis curieux de voir si quelqu'un a une approche différente / meilleure.
Vos branches de production devraient rester intactes. Nommez-les par leur numéro de version. ProduitName_Production_ {Major}. {Mineur}. {Mineur}. Lorsque vous migrez de tests à la production, vous créez une nouvelle branche de production avec le dernier numéro de version. Supprimez la branche de test si vous le souhaitez, mais cela peut être traité de la même manière.
Dans le cadre de mon processus de construction, je me ferme habituellement à la production actuelle avant de déployer la prochaine production afin que je puisse revenir à la dernière version stable si nécessaire. Juste un fyi.
Je n'utilise généralement pas de branches de cette manière cependant. Je garde chaque itération marquée de sorte que je les ai tous. J'utilise mes environnements pour promouvoir le code de Test, à QA, au test de performance, à la production. Ziping chaque colis en cours de route pour les capacités du roulement.
Nous avons le luxe d'être une application Web hébergée (instance unique). Il n'y a donc qu'une seule version en production à tout moment. Nous allons définitivement marquer chaque version lors de leur déploiement; Les 3 branches "actives" existent donc donc nous sommes libres de travailler sur la prochaine grande libération sur le coffre, mais peut corriger des bugs dans le test et la production. (La branche de maintenance peut être un nom meilleur que la branche de production - il existe pour les versions de maintenance, sans refléter ce qui est actuellement en production.)
En fait, nous ne faisons pas la distinction entre la principale branche de travail et la succursale de test du niveau de la version de code, mais cela a du sens pour moi.
Je vais réellement aller pour une approche comme
Lorsque le test est terminé, vous le copiez sur un nouveau dossier / une nouvelle branche.
Je crée une étiquette de la branche ou du coffre pour chaque version.
Si RC1 est acceptable, vous aussi étiquetez-le comme 1.0_ga
Premier: l'option b) et c) sont les mêmes en subversion que dans Subversion Renames sont en fait copie et supprimez.
Cela dit que vous n'avez que deux choix:
Ceci est le propre voie en termes de subversion. Vous pouvez voir dans votre journal SVN que les révisions avaient été fusionnées dans la production et que tous les goodys workingcopy restent intacts.
mais il vient avec un prix:
Vous devez faire la fusion manuellement et résoudre les conflits potentiels (si des modifications du rampe de production se produisent).
Cependant, vous pouvez généralement le faire avec une petite quantité de frais généraux
C'est la méthode easy , car vous venez de faire une très petite opération qui est scriptable.
Inconvénients:
Vous invaliderez tous les fenêtres qui dirigèrent à TestBranch (qui est devenue la production!)
Le suivi fusionné est beaucoup plus difficile, car vous ne pouvez pas examiner facilement l'ancienne branche de production. Les modifications directes de la branche de production sont perdues (sans notification)!
Gardez également à l'esprit que vous ne voudrez peut-être pas que tous les engageurs dans TestBranch dans la production (pourquoi avez-vous été testé, si tout se passe bien?). Donc, je suggérerais fortement
Excellente explication, exactement ce que je cherchais. Merci!
Pourquoi la migration de code est-elle du tout? Faites de la migration à la place!
Pour plus de 4 ans, nous utilisons des succursales. Nous avons pris le coffre et avons fait notre première branche, appelée comme RB-2013.07.0.x. Cette branche est la branche de sortie de juillet 2013. Nous avons enfermé le camion, de sorte que personne ne puisse y apporter des modifications. Tous les changements ont été effectués dans RB-2013.07.0.x. Une fois que la version de juillet a été effectuée, nous avons enfermé la RB-2013.07.0.x, nous n'avons donc donc pas changé.
Entre temps, nous avons également créé une branche RB-2013.09.0.x, pour la libération de septembre, du coffre. Les développeurs ont travaillé sur la version de septembre, tout en travaillant sur la libération de juillet.
Après la sortie de juillet, nous avons ensuite fusionné RB-2013.07.0.x dans RB-2013.09.0.x. Nous ne sommes jamais retournés au coffre. Nous n'avons jamais rien migré. Et dans plus de 4 ans, nous n'avons jamais perdu de code du tout et, lorsque vous avez examiné le projet, vous saviez exactement ce que la branche était pour.
Si vous avez un problème de produit (solution hot-correction), vous prenez la version actuelle du produit - Dites RB-2013.07.0.x et créez une branche RB-2013.07.1.x, apportez vos modifications, déployées dans Prod, Verrouillez la branche et fusionnez la branche dans les branches supérieures - RB-2013.09.0.x. De cette façon, vous aurez tout à jour.
Gardez à l'esprit, chaque bâtiment que nous avons fait, nous avons créé une balise et conservez-la dans le répertoire des balises.
Les constructions que nous avons fait, nous avons ajouté le numéro de révision de SVN à la dernière partie du numéro de construction.
Les constructions iraient de dev, à tester, à UAT / PRE-PROD, puis à prod. Si vous vouliez savoir quel code était dans chaque construction ou une branche, entrez dans SVN et extrayez la liste de journaux.