2016-05-31 2 views
0

Wir verwenden VS und TFS 2010, um ASP.NET-Projekte mit Code, Verzweigungen und Zusammenführungen zu verwalten. All die guten Sachen. Ich komme aus einem Subversion-Hintergrund, daher sind mir einige Aspekte des TFS-Prozesses nicht klar.TFS 2010 - Prüfen, welcher Zweig zum Veröffentlichen verwendet wurde (ASP.NET)?

Eine Sache, die ich wissen muss - rückwärts von einer veröffentlichten Website zu der Branche/Version/Label arbeiten. Wenn ich außerhalb von TFS arbeite, wenn ich über das Dateisystem zum Speicherort navigiere, an dem ein Build veröffentlicht wurde (zum Beispiel auf einem internen IIS-Server), kann ich den Quellcode wie erwartet finden. Ich muss jedoch den Zweig kennen, der zum Ausführen der Veröffentlichungsaktion verwendet wird.

Gibt es etwas eingebautes, das ich verwenden kann, oder ist das eine Build-Aktion, die ich einführen müsste (zum Beispiel den Zweignamen in eine Versionsdatei im Stammprojektverzeichnis einfügen)?

+2

Dies hat nichts mit TFS zu tun, es ist das gleiche mit jedem VCS. * Veröffentlichen Sie nicht aus mehreren Zweigen. Entweder einen einzelnen "Master" - oder "Release" -Abzweig, oder verwenden Sie einen separaten Zweig für jede gut definierte Version. –

+0

Wie haben Sie Ihre Bewerbung veröffentlicht? –

+0

Panagiotis - wir werden für jede gut definierte Version einen separaten Zweig verwenden. Das ist genau der Plan. Sobald Sie jedoch aus diesem Zweig veröffentlichen, was dann? Wenn ich den veröffentlichten Standort betrachte, wie würde ich den Namen des verwendeten Zweigs finden? –

Antwort

0

Wenn Sie den Build in die Warteschlange stellen, sehen Sie im Protokoll den Serverpfad zur Lösung $/teamProject/Project/Project.sln. Der Projektname sollte der Name der Zweigstelle sein.

+0

OK, ich könnte also das Protokoll in einem Build-Ereignis analysieren, um den Serverpfad zu finden, und ihn dann in eine Textdatei im Projektstamm einfügen. Dann könnte diese Datei (nicht unter Versionskontrolle) zusammen mit dem Rest der Web-App veröffentlicht werden. So konnte ich später den veröffentlichten Bereich für die Textdatei überprüfen, um den während der Veröffentlichung verwendeten Zweignamen zu sehen. Klingt das plausibel? –

+0

Im Zweigplan sollte Release Branch ein separater Zweig sein, warum veröffentlichen Sie mehrere Zweige? –

+0

Es ist nicht "Freigabe" so viel wie "veröffentlichen" von den Zweigen. Das Ziel ist es, den veröffentlichten Ort (wo der Build auf dem Webserver landet) zu betrachten und eine Möglichkeit zu haben, rückwärts zur verwendeten Quellcodeversion zu arbeiten. So könnte ein Mitarbeiter zu jedem veröffentlichten Build auf einem beliebigen Webserver wechseln (es können mehrere Builds gehostet werden, verschiedene Funktionen, die auf die einzelnen Builds angewendet werden) und die Version von branch/label/changeset in irgendeiner Weise finden. Dann überprüfen Sie diese genaue Version lokal zu reparieren oder zu untersuchen. –

Verwandte Themen