Subversion: Direction par Environnement?
-
01-10-2019 - |
Question
Je travaille actuellement sur un projet dans .NET qui se compose de plusieurs couches logiques et de multiples frontaux. Voici une représentation grossière de notre structure SVN:
trunk
---doc
---lib
---src
------console
---------console.vbproj
------domain
---------domain.vbproj
------...
------web
---------web.vbproj
---.sln
Toutes notre développement au jour le jour se produit dans le coffre - c'est là tous les développeurs de checkout / engager.
Je cherche un moyen de déployer proprement et facilement entre les environnements (test et de production).
Ma pensée est de créer deux branches, de test et la production, à partir du tronc - solution et tout. Je me Justifiant ce pour les raisons suivantes:
- J'ai un contrôle complet sur lesquels coulent les modifications qui en fusionnant les environnements seulement du tronc à la branche de test et de la branche de test à la branche de production
- je peux voir facilement ce que le code est exécuté dans chaque environnement simplement en regardant le journal de la branche correspondante dans Subversion
Quelqu'un at-il eu une expérience avec une solution similaire à cela? Y a-t-il des pièges potentiels ou oublis que je suis absent?
La solution
Quelqu'un at-il eu une expérience avec une solution similaire?
Oui: -)
Y a-t-il des pièges potentiels ou oublis que je suis absent?
Vous faire face au problème qu'au fil du temps les branches d'essai et de libération dériveront loin de l'environnement de développement que vous très probablement pas fusionner tous les changements de tronc. Les développeurs travailleront ensuite dans un environnement légèrement différent et vous perdre beaucoup de temps en gardant les branches synchronisés. Ceci est connu comme le anti-modèle.
Je conseillerais plutôt de créer une branche de sortie de coffre pour chaque sortie prévue une fois que vous avez toutes les fonctionnalités pour cela mis en œuvre. Au moment où vous ramifier les deux sont égaux. Ensuite, une équipe de stabiliser et de test sur la branche de libération. Le développement va en parallèle sur le tronc. Une fois que votre version a été polie fusion les correctifs avec le tronc.
Répétez la procédure pour chaque version. De cette façon, vous limiter le nombre de fusions et d'avoir les gens qui travaillent sur quelque chose qui est toujours la pointe.
J'espère que ces aspects vous aider dans votre décision. Le lien montre également beaucoup d'autres anti-modèles. Bonne lecture à tous peut-être vous reconnaîtrez quelques leçons apprises et obtiendrez des conseils pour résoudre mieux.
Autres conseils
Nous utilisons la même mise en page sans aucun problème. Assurez-vous d'utiliser la dernière version svn. Version avant 1.5 ne doit pas être utilisé en raison de manque de suivi de fusion.
En conjonction avec un outil de suivi des bogues comme JIRA de Atlassian (je ne suis pas sponsorisé) votre configuration devient encore plus transparent.