Wenn Sie eine TFS-Projektsammlung mit vielen Teamprojekten haben, ist es gängige Praxis, ein "gemeinsames" Projekt zu haben, das eine Sammlung von häufig verwendeten Bibliotheken enthält. Diese Bibliothek kann aus Checkin-Richtlinien, Build-Aktivitäten, MsBuild-Aufgaben und benutzerdefinierten MsBuild-Zielen bestehen. Die Alternative bestand darin, diese Dateien in jedes einzelne Team-Projekt einzuchecken. Dabei besteht die Gefahr, dass sie schnell fragmentiert werden und Sie sich in einer Situation befinden, die sehr schwer zu pflegen ist.
Heutzutage würde ich mich dafür entscheiden, die meisten dieser Abhängigkeiten in ein vsix- oder nuget-Paket zu packen und sie über eine benutzerdefinierte Galerie oder die kommenden Paketverwaltungsfunktionen in Visual Studio Team Services zu verteilen. Lösungen von Drittanbietern wie ProGet und MyGet können diesen Bedarf ebenfalls abdecken.
Leider haben Sie bei der Migration von einem System zu einem anderen nicht die Möglichkeit, die gesamte Lösungsstruktur oder die Art und Weise, wie Abhängigkeiten von Drittanbietern abgerufen werden, auf einmal zu ändern. Daher müssen Sie möglicherweise das alte "Shared Repository"-Muster imitieren, wenn Sie den Build von XAML auf Build 2015 migrieren.
Wenn Sie in Build 2015 eine neue Build-Definition einrichten, werden Sie gefragt, welches Versionskontrollsystem Sie verwenden möchten. Wir entscheiden uns in diesem Fall für Team Foundation Source Control:
Wenn wir zur Seite Repository navigieren, werden Sie sehen, dass das Repository, das zu Ihrem aktuellen Teamprojekt passt, standardmäßig ausgewählt wurde und dass eine Standardzuordnung erstellt wurde:
Im alten XAML-Build-Editor von Visual Studio konnten Sie problemlos Quellen und Artefakte auch aus anderen Team-Projekten zuordnen, aber wenn Sie das Browse-Fenster in Build 2015 öffnen, scheint dies nicht möglich zu sein:
XAML
Bauen 2015
Doch der Schein trügt in diesem Fall. Auch wenn die Dateiauswahl auf das aktuell ausgewählte Team-Projekt beschränkt ist, gibt es in Wirklichkeit keine solche Einschränkung. Wenn Sie die Pfade manuell in die Zuordnung eingeben, werden Sie feststellen, dass sie einwandfrei funktionieren:
Leider funktioniert der Editor weder hier noch in den anderen Aufgaben. Wenn Sie also nach dem Speicherort eines Powershell-Skripts oder einer Lösung irgendwo in einem Projekt suchen, das nicht Ihr Haupt-Repository ist, sind Sie auf sich allein gestellt.
Dies ist jedoch eine Einschränkung der Benutzeroberfläche und nicht des Build-Systems selbst.
So, da haben Sie es. Mit ein wenig manueller Dateneingabe können Sie Ihre alten Builds von XAML auf Build 2015 portieren, ohne dieses Muster sofort ändern zu müssen.
Bemerkung zum Bauumfang
Es kann sein, dass Sie beim Abrufen von Quellen aus mehreren Team-Projekten auf einen Sicherheitsfehler stoßen. Es gibt eine Einstellung, die wir bisher ignoriert haben und die eine Build-Definition auf das Repository beschränken kann, auf das sie ausgerichtet ist. Standardmäßig ist diese Einstellung auf "Projektsammlung" gesetzt, aber wenn Sie Probleme beim Zugriff auf die anderen Repositories haben, kann es sein, dass sie in Ihrem Fall auf "Projekt" gesetzt wurde. Um von mehreren Repositories aus zu bauen, müssen Sie den Geltungsbereich wieder auf "Project Collection" zurücksetzen:
Verfasst von
Jesse Houwing
Jesse is a passionate trainer and coach, helping teams improve their productivity and quality all while trying to keep work fun. He is a Professional Scrum Trainer (PST) through Scrum.org, Microsoft Certified Trainer and GitHub Accredited Trainer. Jesse regularly blogs and you'll find him on StackOverflow, he has received the Microsoft Community Contributor Award three years in a row and has been awarded the Microsoft Most Valuable Professional award since 2015. He loves espresso and dark chocolate, travels a lot and takes photos everywhere he goes.
Contact
Let’s discuss how we can support your journey.