Jak wdrożyć aplikację internetową C# i zarządzać nią z niewielkimi różnicami w stosunku do projektu podstawowego?

Question

Mam pół-dużą aplikację internetową, którą uruchamiamy lokalnie i muszę ją wdrożyć w innej lokalizacji. Druga lokalizacja wymaga niewielkich modyfikacji projektu (szczególnie kosmetycznych). Jak zarządzać tymi różnicami i co używasz do dystrybucji witryny i aktualizacji takiego klienta?

Edycja: Teraz nasza aplikacja internetowa działa w domu i budujemy z Cruise Control .NET i MSBuild z WDP. Jaki byłby dobry wybór dla wdrożenia do klienta? Nie będziemy aktualizować ich strony, więc rozwiązanie, które jest proste do wdrożenia i aktualizacji jest pożądane.

Answer 1

Odgałęzienie kodu.

Mam nadzieję, że Twój kod jest kontrolowany przez źródło (jeśli nie, zacznij teraz!), Powinieneś odejść od bazy do oddziału "Klient X" i dokonać drobnych kosmetycznych modyfikacji w tym oddziale. Następnie zbuduj i rozmieść oddział dla tego klienta.

Dodatkowo, jeśli zmiany są niewielkie, możesz spróbować zmienić konfigurację. W ten sposób możesz wdrożyć tę samą witrynę wszędzie i po prostu zmienić konfigurację tak, aby odpowiadała oczekiwaniom klienta. Im bardziej złożone są różnice, tym trudniejsze będzie ich konfigurowanie.

Po przejrzeniu komentarzy: Warto zauważyć, że konfiguracja jest praktyczna, ale TYLKO jeśli liczba zmian jest niewielka, w przeciwnym razie zanieczyszczenie kodu będzie skutkować logiką konfiguracji. (Dzięki komentatorom)

Tak: Wiele zmian -> Oddział (więcej do utrzymania), kilka drobnych zmian -> Możliwość konfigurowania (bardziej praktyczne).

Answer 2

Własne łatki są z tego powodu bardzo uciążliwe. Zazwyczaj rozgałęziamy się w naszym systemie kontroli źródła i ręcznie stosujemy zmiany po aktualizacji skryptem. Ze względu na dodatkowe obciążenie, w jak największym stopniu odradzamy niestandardowe poprawki.

Answer 3

Zazwyczaj robimy te różnice, kierując się danymi. Różnica klienta to tylko inne ustawienie; każdy inny użytkownik w przyszłości mógłby później ponownie użyć tych samych "niestandardowych" opcji.

Tworzenie "jednorazowych" nie jest skalowane.

Answer 4

Musimy to robić przez cały czas. Staramy się generalizować i różnicować konfiguracje. Najczęstsze powody, dla dostosowania są:

• dodatkowe pola bazy danych: wdrożyliśmy dynamiczny sposób przechowywania tych przedmiotów w dB
układ
• UI: mamy specjalne foldery, w których stawiamy obrazy i pliki CSS, które są załadowane żądać
• różnych obowiązkowych pól wejściowych: możemy przechowywać definicji w konfiguracji i aktywować je programowo
• raporty specjalne: kładziemy pliki w folderze szablonów niestandardowych, aby być wybrany zamiast standardowego szablonu

Niektóre zmiany wymagają zaprogramowania nowych modułów. Kodujemy je w niestandardowej bibliotece, która będzie dynamicznie ładowana do głównej aplikacji.