2013-08-06 6 views
6

Rozumiem, że nie ma obecnie feature request na coś takiego, ale mam nadzieję, że istnieje jakaś obejścia przy użyciu aktualnej wersji (1.6)Użyj innego kanału pakietów w oparciu o środowisko w Octopus Deploy

Budujemy dla naszych środowisk programistycznych i testowych z oddziału dev w TFS i tworzymy dla naszych środowisk kontroli jakości i produkcji z gałęzi wydań w TFS. Ponieważ tworzą one odrębne pakiety nuget, nie mogę używać tego samego pliku danych. Krok instalacji wdrażania nie ma opcji zakresu środowiska. Czy jest jakiś inny sposób, aby powiedzieć "Wdróż pakiet X wersji Y dla Dev/Test i pakiet A wersja B dla QA/produkcji?"

Odpowiedz

6

Ty może korzystać z tego samego kanału, z następującymi zastrzeżeniami:

W nugets zbudowane z dwóch gałęzi oczywiście mieć różne (nie-kolizji) wersje. Dodaję sufiks "dev" do pakietu zbudowanego z gałęzi "dev" (np. 1.2.3.4-dev) i zostawiam moją "stabilną" gałąź.

Podczas tworzenia "wydania" musisz być jednoznaczny, ponieważ Octopus domyślnie wybierze najwyższą dostępną wersję nuget, która może nie być pożądaną wersją (stabilnie prawdopodobnie opóźnia dev). Wybierz wersję pakietu, który chcesz (i odpowiednio ustaw wersję wdrożenia). Jeśli tworzysz wersję za pośrednictwem TeamCity, upewnij się, że użyłeś argumentu --packageVersion oraz ustaw numer wersji.

Ponieważ powyższe działa tylko wtedy, gdy w wydaniu jest tylko jeden pakiet, proces wdrażania (niestety) musi wytworzyć jedną monolityczną nuget, lub otrzymasz niedopasowania wersji.

Zaletą tego rodzaju układ, oczywiście, jest to, że na celowniku ty mógłby Push dev zbudować do QA (lub produktu), jeśli potrzeba kiedykolwiek powstało.

Wszystko to zakłada obydwie gałęzie: zbudować jako ten sam pakiet, oczywiście. Możesz może budować różne pakiety między dev i stabilnych oddziałów (ale nie sądzę, że poleciłbym to ze względu na powielenie wszystkich konfiguracji Octopus).

Aktualizacja: podobno możesz można użyć Octo.exe, aby określić różne numery wersji w różnych pakietach - patrz https://github.com/OctopusDeploy/Octopus-Tools.

+0

To jest zasadniczo ścieżka, którą próbuję podjąć. Jeśli dobrze rozumiem, * dev * jest wstępnym * znacznikiem *. Kilka razy bezskutecznie próbowałem skonfigurować wersję wstępną przy użyciu atrybutu AssemblyInformationalVersion. Do tej pory OctoPack wydaje się ignorować to. Czy dodajesz tag przez ten atrybut, czy po prostu dodajesz go do nazwy pliku po utworzeniu pakietu? – LockeCJ

+0

Wygląda jak AssemblyInformationalVersion [nie jest obsługiwany] (https://github.com/OctopusDeploy/OctoPack/issues/28) przez OctoPack w tym momencie. :( – LockeCJ

+0

Dodałem obsługę funkcji AssemblyInformationalVersion. Oto żądanie pobrania: https://github.com/OctopusDeploy/OctoPack/pull/34 – LockeCJ