J'ai travaillé sur la standardisation de la source de contrôle de la structure de notre Team Foundation Server déploiement pour la nouvelle année. J'ai commencé par utiliser le Microsoft Team Foundation Server Ramification de l'Orientation de la documentation disponible sur CodePlex.
J'espérais obtenir des commentaires et des réponses à quelques-unes des questions spécifiques que j'ai à propos de la structure proposée. Quand il s'agit de la structuration de contrôle de source dans TFS, j'ai appris qu'il y a beaucoup de "normes" à choisir et il n'est pas vraiment une norme.
Tout d'abord, je vais vous présenter et décrire les décisions et l'utilisation.
$/
{Team Project}/
{Subproject}/
Development/
Trunk/
Source/
Tests/
Sandcastle/
TeamBuildTypes/
{Build Name}/
Branches/
{Branch Name}/
Source/
Tests/
Sandcastle/
TeamBuildTypes/
{Build Name}/
Integration/
Source/
Tests/
Sandcastle/
TeamBuildTypes/
{Build Name}/
Production/
Releases/
{Release Version}/
Source/
Tests/
Sandcastle/
TeamBuildTypes/
{Build Name}/
Branches/
{Branch Name}/
Source/
Tests/
Sandcastle/
TeamBuildTypes/
{Build Name}/
La logique générale est qu'une Équipe de Projet peut contenir soit une seule logique de projet (où il n'y aurait pas d' {Subproject} entrée) ou de plusieurs projets liés à la forme d'un produit ou d'un outil de suite. Les trois grands conteneurs sont appelés Development, Integration, et Production.
Au sein de l' Development contenant du Tronc, il y a des dispositions pour les deux projets qui composent le produit dans l' Source le dossier, avec les tests unitaires disponibles dans l' Tests le dossier. Une majorité de mineurs de développement se ferait dans le tronc, avec des branchements disponibles par le biais de l' Trunk le dossier frère de l' Branches le dossier, qui agit comme une ramification du conteneur. Un ou plusieurs fichiers de solution serait de vivre à l'intérieur de l' Trunk, permettant branches au niveau de la capture de la solution, la source, et les tests unitaires.
L' Integration conteneur, souvent appelé "principal" dans les pays non-TFS mise en œuvre, est exclusivement utilisé pour intégrer les Révisions de Development créer un stable et vérifiables construire. Il est à l'origine une branche de l' Development conteneur une fois un testable produit a été atteint. Les versions à partir de ce conteneur sera utilisé pour notre environnement de test et de test de charge de l'environnement. Nous choisissons d'inclure des tests de charge avec testable construit afin que nous puissions surveiller les changements dans la performance, être en mesure d'isoler rapidement les ensembles de Modifications qui peuvent avoir contribué à des irrégularités.
Production est utilisé pour produire de la pré-production et de production de la qualité des constructions. Il est à l'origine une branche de l' Integration conteneur une fois stable construire a été recommandé pour la libération. Au sein de l' Releases le dossier, une branche "par libération" de la structure est suivie, en fournissant des instantanés et de l'isolement dans un lieu unique. (Par exemple, lors de l' Release 1.1 est prêt pour une pré-production de construire, la stable Integration conteneur est ramifiée dans un nouveau Release 1.1 le dossier dans l' Production/Releases de la structure. Ultérieure RCs et RTWs/RTMs sont promus dans ce dossier.) Une ramification de la structure est également présent, comme on le voit dans l' Branches conteneur. Cela permet de "correctifs", généralement une révision marqueur (Majeur.Mineure.De révision). La branche est créée à partir de la version actuelle et fusionnées dans la nouvelle révision de marqueurs, comme Release 1.1.1. La Révision serait inversée intégrée à l' Development du conteneur Trunk lors de l'acceptation.
Nous pensons que cette structure est un juste équilibre entre robustesse et de la complexité. Mais il y a un peu de le harceler de questions que je ne peut logiquement s'insérer dans le modèle. Ils sont les suivants:
L'équipe de Construire - Development et Integration récipients sera d'abord commencer en se nightly builds, éventuellement de passer à l'Intégration Continue (CI). La Production de conteneurs seront fabriqués manuellement.
Où les définitions de build vivre?Edit - Basé sur un couple de réponses, la TeamBuildTypes dossier a été déplacé vers le tronc et les branches à conteneurs appropriés. Ce n'est, toutefois, conduire à une nouvelle question (ci-dessous).En ayant la TeamBuildTypes dossier dans leurs conteneurs, est-ce à dire que toutes les définitions de build sera reproduit entre les dossiers appropriés? Par exemple, avoir une définition de build pour le développement de la qualité s'appuie, ainsi que testable, constructions, etc. toutes les personnes vivant dans tous les TeamBuildType dossiers tout au long de la structure.
La Génération de la Documentation - Nous utilisons des Châteaux de sable pour générer la documentation. Plus précisément, nous utilisons également Sandcastle Help File Builder pour gérer la sortie. Cela produit un fichier de projet dans un format propre à SFHB.
Devrait documentation générée être stockées dans la source de contrôle de la structure?
Devrait documentation être généré pour chaque conteneur, ou il ne fait que posséder une valeur pour la pré-production et de la qualité de la production s'appuie?
Pour préserver local rapide, les temps de réalisation, devrait création de documentation être la propriété d'une définition de build?
Où doit SHFB les fichiers spécifiques à vivre? Ma première idée est de le mettre en tant que pair à l'Je suis d'accord avec le recommondations qu'il soit un peer-to -SourceetTestsdes dossiers.SourceetTests. Schéma modifié pour refléter ce changement.
Troisième Partie Binaires
Devrait binaires (contrôles, les bibliothèques, etc.) être stockés dans le contrôle de code source?
Si oui, devrait-il être son propre Projet d'Équipe?
Documentation générale - Non-documentation générée, telles que les exigences, les documents de conception, plans de test, etc. ne vont pas être traduit par un dossier dans le contrôle de source de la structure. Après quelques recherches et discussions avec mes développeurs et les pairs, à l'aide de l'intégré dans le dossier Documents dans Team Explorer offre plus d'avantages, car il reflète la structure au sein de l'Équipe Projet de Portail et certains (d'affaires), les utilisateurs n'ont pas besoin de la complexité de l'apprentissage de la source de contrôle de l'aspect de la TSF.
Je vais mettre à jour la structure que je reçois des réponses aux questions de fournir une image plus claire. Je souhaite également la bienvenue à tout les autres commentaires relatifs à d'éventuelles modifications. Si j'ai d'autres questions, je ferai en sorte de modifier ce post.
Modifications:
Des précisions.
SourceetTestsdes dossiers ne vivre sous l'Integrationconteneur, ainsi.Les deux Micah et Josh a apporté de grands points concernant la troisième partie binaires. Question relative à la question.
La génération de la Documentation peut être lent. Question ajoutée quant à savoir si la création de documentation doit être possédé par une Équipe spécifique au Type de Build.
Ajouté résolution relative à la non-documentation générée, telles que les exigences, les documents de conception, plans de test, etc.
Ajouté résolution relative à la TeamBuildTypes dossier de construction de définitions.
Basé sur divers commentaires, déplacé les TeamBuildTypes dossier de la branche trunk / niveaux.
