Konfiguracja projektu usługi chmury Azure (.csdef i .cscfg) w wielu środowiskach

Question

Obecnie mamy usługi w chmurze rozwoju (acme-dev-service) i usługi chmury produkcyjnej (acme-prod-service). Nasza obecna konfiguracja w naszym rozwiązaniu ma projekt usługi w chmurze o nazwie acme.application, który wykorzystuje transformację plików .cscfg i .csdef w celu wdrożenia projektu w dwóch środowiskach (produkcja i rozwój). Nie podoba mi się metoda transformacji, ponieważ wydaje mi się, że jest dla mnie trochę hackowania. Po przeprowadzeniu badań wydaje się, że możesz mieć wiele plików konfiguracyjnych, które rozwiązują część problemu, ale mam problemy, ponieważ masz tylko jedną definicję usługi. Nie działa to dla nas, ponieważ środowisko produkcyjne wymaga dodatkowych certyfikatów, a także różnych wiązań hostHeader, niż ma to miejsce w naszym środowisku programisty.

Wygląda na to, że naprawdę nie możemy korzystać z transformacji. Sądzę więc, że moje pytanie sprowadza się do tego, że patrzę na pliki projektu Azure Service w złym świetle? Czy naprawdę powinniśmy mapować jeden projekt Azure do jednej usługi chmurowej Azure? Czy powinienem mieć projekt Azure dla produkcji i drugi Azure Project for Development? Czy jest lepszy sposób to zrobić? Lub najlepszą praktyką do pracy z wieloma środowiskami na platformie Azure?

Answer 1

Plik CSDefinition jest tutaj prawdziwym kopnięciem. Jeśli masz wartość, musisz różnić się między dwoma środowiskami (dev/test/stage/production, itp.), To naprawdę masz trzy opcje:

1) Ręcznie zmodyfikuj wartość przed wdrożeniem. Errr .... OK .... masz dwie opcje.

1) Stuknij w proces budowania MS i określ, którą konfigurację chmury wybrałeś (tą używaną do określenia, która wersja pliku .cscfg zostanie wykorzystana), a następnie zmodyfikuj kompilację .csdef po kompilacji i przed pakowaniem (jest czas, kiedy plik został skopiowany do innego katalogu tuż przed zapakowaniem i tam właśnie chcesz dokonać zmiany). Może to być trudne, chociaż widziałem, jak to się stało, a nawet zrobiłem to we wczesnych dniach SDK. Oto blog opisujący jeden przykład, w którym używa On WebConfigTransformRunner, aby to zrobić: http://fabriccontroller.net/blog/posts/apply-xdt-transforms-to-your-servicedefinition-csdef-file/. Nie sądzę, że jest to najlepsza opcja, ponieważ jest nieprzejrzysta. Nie jest oczywiste, co się dzieje, a ktoś, kto przychodzi po tobie, by zachować kod, nie będzie wiedział o tym małym klejnocie i spędzi na zawsze próbując dowiedzieć się, dlaczego niektóre wartości, które umieścili w csdef gdzieś, są w jakiś sposób nadpisywane po opublikowaniu. inne środowisko.

2) Użyj wspomnianego podejścia do dwóch projektów Azure. Można skonfigurować definicje kompilacji w wybranym narzędziu Budowanie, które określają projekty Azure, które chcesz utworzyć i opublikować. Osobiście uważam, że jest to najlepszy sposób radzenia sobie z różnymi plikami .csdef. Jest prosty i nie wymaga modyfikacji plików csproj. Nie jestem przeciwnikiem zmiany pliku csproj, to nie jest zbyt oczywiste, że zostało to zrobione i mówiąc, jako ktoś, kto odziedziczył takie rzeczy, nie jest łatwo znaleźć, kiedy ludzie robią tego rodzaju rzeczy i nie są w pobliżu, aby powiedzieć ty o tym.