Unser kleiner Entwicklungsladen versucht, unsere Projekte von VSS auf TFS zu migrieren, und wir bewerten TFS im Vergleich zu anderen (haben noch nicht den Auslöser gezogen). Die Natur unseres Softwareshops ist so, dass wir mehr als 100 Projekte in VSS haben, angefangen von kleinen Ein-Mann-Show-Projekten bis zu massiven unternehmensweiten Anwendungen.
Wir versuchen zu bestimmen, wie wir unsere Projekte im Übergang strukturieren können und haben uns größtenteils dafür entschieden, alles in eine Projektseite / ein Projekt zu setzen, wobei jedes Projekt einen Unterordner von der Wurzel hat.
Bei dieser Art von Installation sind wir besorgt, dass wir einen Großteil der Funktionalität von TFS verlieren werden (Bug-Tracking, Scrum-Burndowns, Reporting, Dokumentenspeicherung usw.), da sich alle Projekte im selben Portal / Projekt befinden Raum und es wird schwierig sein, einzelne Projekttickets / Artikel zu trennen.
Hat jemand Erfahrung damit? Was war deine Lösung? Hast du bei TFS geblieben?
Die Antwort auf diese Frage erfordert eine gewisse Planung auf Ihrer Seite: Wie beabsichtigen Sie, TFS zu verwenden und welche dieser Fähigkeiten hat inhärente Einschränkungen für das Produkt? Ich würde meinen Ratschlag wie folgt zusammenfassen:
Sie benötigen [mindestens] 1 Teamprojekt pro Prozessvorlage. Das heißt, wenn zwei Teams unterschiedliche Prozesse übernehmen / anpassen möchten, müssen sie getrennt werden.
Sobald Bedingung 1 erfüllt ist, brauchen Sie wahrscheinlich nicht mehr so viele separate Teamprojekte, wie Sie denken. 90% der TFS-Funktionen & amp; Die Einstellungen sind hierarchischer Natur, sodass Sie sie so breit oder eng definieren können, wie es für jedes Ihrer Projekte erforderlich ist.
Weitere Einzelheiten finden Sie unter
Der Ansatz, den ich gewählt habe, war ein TFS-Projekt für jede logische Gruppierung von Assemblys - also haben wir ein Framework-Projekt, das für alle unsere Anwendungen gemeinsame Assemblies enthält, wir haben dann ein eigenes Projekt für unser Angebotssystem, ein anderes für das Kostensystem und so weiter. Während die Arbeitsbereichszuordnungen ein bisschen "interessant" werden, erlaubt es unterschiedliche Entwurfsmethoden für verschiedene Projekte und zu verschiedenen Zeitskalen - so kann ein Team die Hälfte eines Sprints zurücklegen (Die meisten Projekte verwenden Scrum for Team System ), während gleichzeitig eine andere gerade anfängt ...
Es ist wahr, dass es am besten ist, um alle Vorteile von TFS zu nutzen, separate Projekte zu verwenden, aber diese Vorteile sollten gegen den Verwaltungsaufwand abgewogen werden, der mit der Verwaltung vieler Projekte verbunden ist. Vor Jahren habe ich Visual Source Safe verwendet ... Nachdem ich Microsoft verlassen hatte, wechselte ich zu Subversion. Nach der Rückkehr zu Microsoft benutze ich TFS und bisher bin ich sehr zufrieden damit.
Die Prozessführung, die Berichte, das integrierte Bugtracking und die enge IDE-Integration erfüllen meine Bedürfnisse perfekt. Außerdem ermöglicht das TFS SDK einige interessante Erweiterbarkeitsszenarien.
Ich habe mehrere SCC-Anbieter verwendet und wir haben uns für TFS für alle Funktionen entschieden, die andere Anbieter nicht haben. Fehlerkorrelation, CI und automatisiertes Testen standen sicherlich an erster Stelle.
Ob Sie mehrere Projekte verwenden oder nicht, würde ich sagen, es hängt davon ab, ob die Projekte einen gemeinsamen Code teilen. Wir neigen dazu, ein TFS-Projekt für alle "verwandten" Code-Assets zu verwenden. Wenn wir also mehrere verschiedene Lösungen haben, die ähnliche Dinge tun und viel Code gemeinsam nutzen, verwenden wir ein einzelnes TFS-Projekt. Wenn sie nichts gemeinsam haben, werden sie zu getrennten Projekten.
Ich bin nicht sicher, ob dies 2008 behoben wurde, aber 2005, als Sie ein Projekt erstellt haben, das ein Unterordner eines Stammprojekts war, wird MSBuild den gesamten Quellbaum des Stammprojekts ziehen - sogar Dateien, die nicht Teil Ihres Stammprojekts sind Unterordner.
Je nachdem, wie viel Quelle Sie verwalten, kann dies Ihre Build-Zeiten erheblich erhöhen.
Ich weiß, dass dieser Artikel alt ist, aber TFS 2010 unterstützt nun einen wunderbaren Feature-Aufruf Team Project Collections, der einfach eine andere Ebene der Indirektion oder Gruppierung über Projekte ist.
Dies macht es viel einfacher, Team-Projekte zu erstellen, ohne Ihren Namensraum zu blockieren und fördert eine bessere Organisation!
Great Link spricht mehr über Sammlungen
Ich bin kein Sharepoint-Benutzer, aber ich höre sein sehr ähnliches Konzept zu Sharepoint-Sammlungen:)
Tags und Links tfs version-control team-project