TFS-build-server bauen, der Zweig?
Haben wir einen TFS 2008-Projekt mit zwei Filialen ("Haupt -" und "NewFeature").
Jeder ist eine komplette, unabhängige "kopieren" (Variante) der source-code.
Durch ändern der workspace-mappings, wir können die Karte entweder Variante, die auf unseren lokalen PCs gearbeitet haben und mit beiden äste ohne Probleme.
Jedoch, wenn ich die Zuordnungen wechseln unser build-server, auf dem branch NewFeature (die sollten tauschen Sie einfach nur in die NewFeature-source-code ohne etwas zu ändern sonst soweit auf dem build-server betroffen ist) bekomme ich Fehler:
There is no working folder mapping for $/Main/Product.sln
D. H. wenn es sich um Gebäude aus der branch NewFeature, etwas ist immer noch auf der Suche in der Main Zweig, obwohl es keine Hinweise irgendwo in den Quellcode zu diesem Zweig. Es scheint caching einen Hinweis auf die Wichtigsten?!
Ich habe eine komplett saubere bauen (gelöscht, den Ordner aus dem server, und führen Sie den build mit /p /p:ForceGet=true, um sicherzustellen, dass die Zuordnung geleert wird, durch den server, und es gibt keine Dateien auf dem server, könnte der cache workspace-Bindungen), aber das hilft nicht.
Irgendwelche Vorschläge?
InformationsquelleAutor Jason Williams | 2009-12-02
Du musst angemeldet sein, um einen Kommentar abzugeben.
Stellen Sie sicher, dass:
/BEARBEITEN /
Beachten Sie jedoch, es ist nicht wichtig, dass $/Main $/Branches/Feature live auf der gleichen Ebene in der Hierarchie. Auch sollte der lokale Pfad auf dem server zu bauen Angelegenheit.* Alles was zählt ist, was darunter ist jede Verzweigung. Wenn die Inhalt intern konsistent ist, dann werden alle Ihre vorhandenen build-Skripte sollte ohne Modifikation funktionieren.
Konkrete Beispiele, wie ich mag, um alles miteinander zu verbinden, siehe meinen letzten Antworten, z.B.:
Mein Weg ist nicht der einzige Weg, aber ich kann bezeugen, dass es funktioniert besser als alle anderen Varianten, die ich habe festgestellt im Laufe der Jahre 🙂
*Ehrlich gesagt, versuchen, micromanage Team Bauen können mittlerweile viel mehr schmerzhaft ist als die vorgeschlagene Umstrukturierung Ihrer MSBuild-Skripts. Für die Zuverlässigkeit, die Sie haben zu Ort Ihre tfsbuildservice.exe.config-Anpassungen unter Versionskontrolle irgendwo...wenn du >1 build-server (oder möglicherweise in der Zukunft), dann haben Sie zu prüfen, eine Veränderung Strategie für die Bereitstellung...Sie am Ende brauchen eine meta-SCM-Prozess zu verwalten Sie Ihren SCM-Prozess!
Jubel für takig die Zeit, um dieses detail, Richard. Ich werde haben eine gute Lesen. Ich will einfach nur zu Sortieren, die TFS best practices vor massiven Veränderungen, anstatt zu viel Aufwand, und dann herauszufinden, dass es nicht funktioniert, dass Art und Weise!
Akzeptierte Antwort, wie die anderen Antworten, die genau beschreiben, meine geplante Verzweigung-Struktur, was darauf hindeutet, dass ich mindestens barking up the right tree 🙂
Ich habe gerade einen weiteren Riss an diesem problem und tatsächlich löste es sauber dieses mal. Es stellt sich heraus, Sie waren an Ort und Stelle mit Ihrer Antwort, es nahm mich eine Weile, um herauszufinden, wie man es anwenden 🙂 Wenn du Interesse hast, ich habe eine neue Antwort auf diese Frage detailliert die situatin (falls jemand zuschlägt ist das gleiche problem in der Zukunft).
Ich weiß, das ist alt, aber ich bin auch mit dem gleichen problem, und versuchte, einen Zweig, die ich heruntergeladen habe aus meinem TFS-2012-server. Obwohl die Niederlassung ist MyProject_v1_0_0_1, wenn ich die Warteschlange ein TFS build, TFS beschwert sich und sagt: Es gibt keine funktionierenden Ordner-mapping für $/MyProject/Main/Projekt.sln. Wie kann ich "$(SolutionToBuild) verwendet einen relativen Pfad beim Verweis auf Produkt.sln"? Danke.
InformationsquelleAutor Richard Berg
Ich hatte auch dieses problem, wenn ein build aus einer Niederlassung in TFS 2010. TFS wurde berichtet, dass "gibt Es keine Arbeits-Ordner-mapping für $/Main/Product.sln", Die Lösung stellte sich heraus, dass das Bearbeiten der build-definition wie folgt (ich verwende die "Standard-Vorlage" build-process-template—ich habe nicht versucht, diese mit einer benutzerdefinierten Vorlage):
+1. Auch hat mir geholfen, eine Menge.
InformationsquelleAutor user261190
OK, die Ergebnisse sind da - ich habe einen workaround gefunden.
Aufgrund unserer legacy build-Prozesse (erstellen, kopieren, verschleiern, bauen Sie benutzerdefinierte Installationsprogramme kopieren, um die drop-Ordner), kann ich nicht einfach den Zweig neben der wichtigste Zweig. Es muss ersetzen.
So, wenn ich Haupt-und NewFeature, ich möchte unmap Haupt-und map-NewFeature an seiner Stelle (D. H. mit "c:\Main" auf dem build-server, und ändern Sie einfach den Quelle-code, der dort erscheint)
Lösung #1 (die einfache, naheliegende und logische Lösung) ist die Verwendung dieser Zuordnungen:
Erwartete Ergebnis: NewFeature code-Struktur ersetzt einfach Main, und der build-server nicht weiß, dass es auf einen anderen Zweig.
Tatsächliche Ergebnis: Fehler mit "bist du noch nicht abgebildet $/Main-auch wenn man es nicht mit" Fehler.
Lösung #2 ist, dies zu tun:
Dies funktioniert (es unterdrückt die Warnung, und ermöglicht so einen build zu gehen mit MSBuild nicht bewusst, dass es sich um Gebäude in einem Zweig). Jedoch, es ist hässlich und der build wird alle Haupt-Zweig-source-code unnötig.
Lösung #3 (ungetestet, zu teuer, zu versuchen, es sei denn, ich weiß, dass es funktioniert viel besser als #2):
Hoffe, dass ich dann die Karte nur in der Filiale, die ich brauche und Bearbeiten TFSBuild.proj umgeleitet zu bauen in dieser Filiale.
(Edit: ja, das funktioniert gut. Wir haben jetzt neu organisiert, unsere gesamte code-Struktur, so dass alles (alle Filialen) unter einer gemeinsamen Wurzel zu einem Team-Projekt, und Verzweigung/Aufbau ist kein problem mehr - es ist einfach zu tun, was wir jetzt brauchen. Der trick ist, legen Sie eine root-Ordner in der Hierarchie, so dass Sie verzweigen können auf jeder Ebene, die Sie mögen. Ich habe ein kleine zwicken, um das build-Skript, so dass wir passieren können den branch zu erstellen, die als parameter MSBuild, so dass es leicht zu erstellen eine Variante, die jetzt. Alle Zweige, die wir nicht arbeiten will, kann einfach getarnt werden und der build-server bleibt glücklich.)
Zusammenfassung
Alle diese Lösungen (fachlich) saugen. Sie haben die Neuzuordnung der Arbeitsbereich (in diesem Fall, es ist nicht einfach: 9 mapping-Einträge erforderlich sind, so ist es eine fehleranfällige und mühsame Sache zu tun), Bearbeiten Sie die TFSBuild.proj, löschen Sie alle source-code, und führen Sie einen build mit /p /p:ForceGet=true zu wechseln, die bauen zwischen Zweigen. So dauert es etwa eine Stunde zu wechseln Zweige. Unglaublich - es sollte ein paar Minuten bei den meisten!
Ich erkennen, unser Projekt ist weit von ideal, aber ich kann es nicht glauben, sollte diese schwer zu Filiale in TFS (Es war ein Stück Kuchen in SourceSafe, Accurev, und Notgedrungen, also warum so schmerzhaft in TFS?).
Wie auch alle anderen mit der Organisation Ihres TFS-Filialen? Wie wollen Sie wechseln die Entwickler zwischen den Zweigen? Wie schalten Sie server baut zwischen den Zweigen? Ist es wirklich zu dieser schmerzlich?
InformationsquelleAutor Jason Williams
Beim Bearbeiten der build-definition gibt es zwei Orte, die geändert werden müssen.
Hoffe, das hilft.
InformationsquelleAutor Ankit
Neues update:
Wie bereits in der anderen Antwort, ich fand einen workaround, das war ok für ein kurzes feature-branch, aber es ist wirklich nicht sehr gut funktionieren. Ich hab da wieder zu dem problem, und die Lösung ist lächerlich einfach:
In der TFSBuild.proj, war der Weg basierend auf $(BuildProjectFolderPath). Dieser Pfad wird in einen server-Seite (source-control-Pfad) wie $/Main - nicht mit einem lokalen Pfad (D:\ServerBuildFolder\Main).
Leider aus historischen Gründen unser source-code ist verteilt über mehrere team-Projekte, was bedeutet, dass der eine "Zweig" ist zersplittert in mehrere verzweigte Ordner im Source Control (d.h. $/Main/Code und $/Bibliotheken/Code. Sie können nicht erstellen Sie einen Zweig, der enthält $/Main $/Bibliotheken). Wir müssen also wieder zusammenbauen, die verschiedenen Fragmente aus der Quellcodeverwaltung wieder in eine kohärente Hierarchie mithilfe von workspace-Zuordnungen.
Bedeutet dies, dass Richard auf den Punkt brachte - der relative Pfad von der TFSBuild.proj-Datei, um die .sln-Datei war fehlerhaft, da MSBuild/TFS geht davon aus, dass die .sln liegt im gleichen Team, Projekt und source-control-Hierarchie (so war auf der Suche für $/Haupt - /Bibliotheken.sln statt $/Bibliotheken/Bibliotheken.sln).
Die Lösung ist einfach: ich Ersetze $(BuildProjectFolderPath) mit einem lokalen Pfad (z.B. D:\ServerBuildFolder\Main) für die Dateien, so dass die relative Referenz gelöst wurde, in den "lokalen Raum" (nach der mappings angewandt wurde), und MSBuild wird nun ausgeführt süß.
Die moral von der Geschichte:
1) verwenden Sie NIE mehr als ein Team-Projekt, wenn es irgendeine chance, dass Sie jemals wollen, um irgendeine Art von Referenz, die zwischen diesen code-Basen. Lassen Sie sich nicht täuschen zu denken, dass ein neues Team-Projekt bieten eine Art schmerzlose logischen Unterscheidung zwischen Anwendungen/Bibliotheken. Zusätzliche Projekte haben bewiesen, zu sein ein Verwaltungs-Alptraum - Lasten von zusätzlichen Problemen für absolut null nutzen. (Es ist alles ein großes gemeinsames Haufen unter der Motorhaube, so dass alle Arbeitsaufgaben und source-control-Ordner sind noch sichtbar in alle Projekte (!), aber es fügt ein paar Mauern, die machen inter-Projekt-links sehr problematisch)
2) Immer in ein einzelnes root-level-Ordner in Ihrem Projekt-Team-Quellcodeverwaltung, und dann alles andere unter diesem Ordner. z.B. Für das Projekt "$/Main" erstellen "$/Main/Root" und dann alles von Ihrer Quelle Hierarchie innerhalb Stamm.
Durch die folgenden Regeln, werden Sie in der Lage sein zu verzweigen, die einzigen "Root" - Ordner in der Zukunft, und wird dann mit nur einer einzigen Niederlassung und eine einzelne extra-workspace-mapping. Dies wird Ihnen helfen, vermeiden Sie vorzeitigen Haarausfall.
(In meiner Verteidigung, ich hätte es getan, auf diese Weise zu beginnen - ich arbeite mit legacy-setup. In der Verteidigung der legacy-setup, es klingt auf dem Papier gut aber ist nicht nur ein Microsoft-unterstützten Ansatz!)
InformationsquelleAutor Jason Williams
Bekam ich diese Fehlermeldung und ich ergründen kann, ist, dass die definition wurde beschädigt oder so etwas. Ich habe gerade umgestrickt die Prozess-Sachen (re-Hinzugefügt, die Lösung, die ich versuchte zu bauen) und Arbeitsbereiche neu zugeordnet und es begann wieder zu arbeiten. HTH.
InformationsquelleAutor Mike Cheel