2015-09-01 12 views
11

Mamy projekt, który może korzystać z dwóch różnych wersji danej biblioteki DLL. Potrzebujemy tego wdrożonego w dwóch różnych środowiskach. Która wersja biblioteki DLL jest używana, powinna zależeć od środowiska.Jak używać ośmiornic w różnych wersjach zestawu zależnego w różnych środowiskach

Jednym z sugerowanych rozwiązań jest skopiowanie całej bazy kodu i utworzenie konfiguracji wdrożenia ośmiornicy na podstawie tych dwóch baz kodów.

Jestem zdecydowanie przeciwko temu, ale wciąż nie mam rozwiązania tego problemu.

Myślę, że przekierowanie binarne nie będzie działać, ponieważ nie mogę określić ścieżki dll w konfiguracji i oczywiście nie mogę mieć tych dwóch plików w tym samym katalogu.

Wszelkie pomysły?

+1

Co próbujesz osiągnąć, wdrażając różne wersje w zależności od środowiska? Generalnie Octopus wdraża te same pliki do każdego środowiska, więc lepiej zastosować inne podejście. – tspauld

+0

Myślę, że to, co próbujesz zrobić, jest możliwe - ale * nie * zalecane. Do tego punktu, ja też byłbym przeciwny temu, ale nie do końca rozumiem, dlaczego dwie różne wersje DLL musiałyby być wdrożone - wydaje się to sprzeczne z intuicją. Czy możesz wyjaśnić swoją sytuację trochę więcej? – osij2is

+0

Mamy agenta transportu MS Exchange. Codebase może i pozostanie bez zmian, jedyną różnicą jest odniesienie do biblioteki MS MS dla wersji 2013 i 2016. W zależności od środowiska (2013 i 2016) chcielibyśmy odwoływać się do różnych bibliotek dll. Pliki DLL mają taką samą nazwę, wersja jest inna. –

Odpowiedz

2

Może to być łatwo rozwiązane przez skrypt powershell, jako etap wdrażania Octopus. Na przykład, projekt może mieć dwa pliki:

YourFile.dll 
YourFile.v2.dll 

Następnie skrypt PowerShell, po kroku, (pseudokod) będzie wyglądać coś podobnego:

if($OctopusParameters["environment"] == "Dev") { 
    File.Delete("YourFile.dll"); 
    File.Rename("YourFile.v2.dll", "YourFile.dll"); 
} 

Zgadzam się jednak, że jest to dość nietypowy problem i może wskazywać na zapach kodu.

Powiązane problemy