Comment organiser le contrôle de la source pour plusieurs projets en fonction des projets communs à SharePoint 2013

Question

Je suis juste pour créer un nouveau projet Big SP 2013, j'étudie différentes façons d'organiser la structure VS et l'une des façons que j'ai aimées est de séparer par exemple WebParts dans différentes solutions:

http://bitofthough.blogspot.in/2012/ 05 / Visual-Studio-SharePoint-Solution.html

En outre, certaines bibliothèques seront communes à tous les projets.

La chose qui me tourne fou est que nous utiliserons Server Team Foundation Server et dans TFS, chaque projet dispose de ses propres éléments de travail et de son référentiel de contrôle de la source de travail.

permet de dire que je fais une application HR, puis je crée le projet HR TFS avec des éléments, des tâches, des bogues, etc.

Mais, qu'en est-il des projets courants à l'extérieur des ressources humaines, disons que HR utilise 3 projets WebPart et une bibliothèque commune à tous les projets. Comment organiseriez-vous ces projets "externes" ou "communs"?

Devrais-je créer un projet TFS aussi pour chacun d'entre eux? ou un pour tous mais sans workitems, etc.

Answer 1

For groups that do a lot of small projects, sometimes it's best to have a TFS project for the Team, and not multiple projects per development project. For example, perhaps you're using scrum, and your backlog has items from HR and other groups. But, even though there are different "projects" with different deadlines and even different technologies, it's treated as one backlog. So, there's one daily scrum meeting where all of the smaller projects are discussed. And, there's one sprint, where folks spend time working on pieces of different projects. And, of course, this means that there is one TFS project to manage work items and such.