Jak wdrażać aplikacje ASP.NET na serwerach działających?

Szukam różnych technik / narzędzi, których używasz do wdrażania projektu aplikacji sieci Web ASP.NET ( NIE witryny sieci Web ASP.NET) do produkcji?

Szczególnie interesuje mnie przepływ pracy między momentem, w którym serwer Continuous Integration Build upuszcza pliki binarne w jakiejś lokalizacji, a momentem, w którym pierwsze żądanie użytkownika trafia do tych plików binarnych.

1. Używasz jakichś konkretnych narzędzi czy po prostu XCOPY? Jak jest spakowana aplikacja (ZIP, MSI, ...)?

2. Kiedy aplikacja jest wdrażana po raz pierwszy, jak skonfigurować pulę aplikacji i katalog wirtualny (czy tworzysz je ręcznie czy za pomocą jakiegoś narzędzia)?

3. Kiedy zmienia się zasób statyczny (CSS, JS lub plik obrazu), czy ponownie wdrażasz całą aplikację, czy tylko zmodyfikowany zasób? Co powiesz na zmianę strony zestawu / ASPX?

4. Czy śledzisz wszystkie wdrożone wersje dla danej aplikacji, a jeśli coś pójdzie nie tak, masz procedury przywracania aplikacji do poprzedniego znanego stanu roboczego?

Zapraszam do uzupełnienia poprzedniej listy.

A oto, czego używamy do wdrażania naszych aplikacji ASP.NET:

1. Dodajemy projekt wdrażania sieci Web do rozwiązania i konfigurujemy go do tworzenia aplikacji sieci Web ASP.NET
2. Dodajemy projekt konfiguracji ( NIE projekt konfiguracji sieciowej) do rozwiązania i ustawiamy go tak, aby pobierał dane wyjściowe projektu wdrożenia internetowego
3. Dodajemy niestandardową akcję instalacji iw zdarzeniu OnInstall uruchamiamy niestandardowy zestaw kompilacji .NET, który tworzy pulę aplikacji i katalog wirtualny w usługach IIS przy użyciu System.DirectoryServices.DirectoryEntry (to zadanie jest wykonywane tylko przy pierwszym wdrożeniu aplikacji) . Obsługujemy wiele witryn sieci Web w usługach IIS, uwierzytelnianie dla katalogów wirtualnych i ustawianie tożsamości dla pul aplikacji.
4. Dodajemy niestandardowe zadanie w programie TFS, aby zbudować projekt instalacji (TFS nie obsługuje projektów instalacyjnych, więc musieliśmy użyć devenv.exe do zbudowania MSI)
5. MSI jest instalowany na serwerze rzeczywistym (jeśli istnieje poprzednia wersja MSI, jest najpierw odinstalowywana)

Mamy cały nasz kod wdrożony w MSI przy użyciu Setup Factory. Jeśli coś musi się zmienić, wdrażamy ponownie całe rozwiązanie. Brzmi to jak przesada dla pliku css, ale absolutnie synchronizuje wszystkie środowiska, a my dokładnie wiemy, co jest w produkcji (wdrażamy we wszystkich środowiskach testowych i uat w ten sam sposób).

Robimy wdrażanie stopniowe na serwery na żywo, więc nie używamy projektów instalatorów; mamy coś bardziej podobnego do CI:

• Kompilacje „na żywo” serwera kompilacji z zatwierdzonego źródła (nie „HEAD” repozytorium)
• (po wykonaniu kopii zapasowej ;-p)
• robocopy publikuje na serwerze pomostowym („na żywo”, ale nie w klastrze F5)
• ostateczna weryfikacja przeprowadzona na serwerze pomostowym, często z hackami „hostów”, aby jak najdokładniej emulować całość
• robocopy / L jest używane automatycznie do dystrybucji listy zmian w następnym „push”, aby ostrzec o wszelkich błędach
• w ramach zaplanowanego procesu klaster jest cyklicznie wdrażany do węzłów w klastrze za pośrednictwem robocopy (gdy są poza klastrem)

robocopy automatycznie zapewnia, że ​​wdrażane są tylko zmiany.

Ponownie pula aplikacji itp .; Ja kocham to być zautomatyzowane ( patrz na to pytanie ), ale w tym momencie to jest instrukcja. Naprawdę chcę to zmienić.

(prawdopodobnie pomaga to, że mamy własne centrum danych i farmę serwerów „na miejscu”, więc nie musimy przekraczać wielu przeszkód)

Stronie internetowej

Wdrażający: http://www.codeproject.com/KB/install/deployer.aspx

Publikuję witrynę w folderze lokalnym, spakuję ją, a następnie przesyłam przez FTP. Wdrażający na serwerze następnie rozpakowuje zip, zamienia wartości konfiguracyjne (w plikach Web.Config i innych) i to wszystko.

Oczywiście przy pierwszym uruchomieniu musisz połączyć się z serwerem i skonfigurować IIS WebSite, bazę danych, ale później publikowanie aktualizacji to bułka z masłem.

Baza danych

Aby utrzymać synchronizację baz danych, używam http://www.red-gate.com/products/sql-development/sql-compare/

Jeśli serwer znajduje się za grupą routerów i nie możesz połączyć się bezpośrednio (co jest wymagane w przypadku porównania SQL), użyj https://secure.logmein.com/products/hamachi2/, aby utworzyć VPN.

Wdrażam głównie aplikacje ASP.NET na serwerach Linux i wdrażam wszystko ponownie, nawet przy najmniejszej zmianie. Oto mój standardowy przepływ pracy:

• Używam repozytorium kodu źródłowego (jak Subversion)
• Na serwerze mam skrypt bash, który wykonuje następujące czynności:
  • Sprawdza najnowszy kod
  • Czy kompilacja (tworzy biblioteki DLL)
  • Filtruje pliki do najważniejszych (na przykład usuwa pliki z kodem)
  • Tworzy kopię zapasową bazy danych
  • Wdraża pliki na serwerze sieci Web w katalogu o nazwie z bieżącą datą
  • Aktualizuje bazę danych, jeśli we wdrożeniu uwzględniono nowy schemat
  • Ustawia nową instalację jako domyślną, więc zostanie wyświetlona przy następnym trafieniu

Pobieranie odbywa się za pomocą wersji Subversion z wiersza poleceń, a budowanie odbywa się za pomocą xbuild (podobnie jak MSBuild z projektu Mono). Większość magii jest wykonywana w ReleaseIt.

Na moim serwerze deweloperskim zasadniczo mam ciągłą integrację, ale po stronie produkcyjnej faktycznie wysyłam SSH do serwera i inicjuję wdrożenie ręcznie, uruchamiając skrypt. Mój skrypt jest sprytnie nazywany „wdrażaniem”, więc to właśnie wpisuję w wierszu polecenia basha. Jestem bardzo kreatywna. Nie.

W środowisku produkcyjnym muszę dwukrotnie wpisać „wdrożenie”: raz, aby wyewidencjonować, zbudować i wdrożyć w przestarzałym katalogu i raz, aby ustawić ten katalog jako domyślną instancję. Ponieważ katalogi są przestarzałe, mogę powrócić do dowolnego poprzedniego wdrożenia, po prostu wpisując „wdrożenie” w odpowiednim katalogu.

Pierwsze wdrożenie trwa kilka minut, a powrót do poprzedniej wersji zajmuje kilka sekund.

Było to dla mnie miłe rozwiązanie i opiera się tylko na trzech narzędziach wiersza poleceń (svn, xbuild i releaseit), kliencie DB, SSH i Bash.

Naprawdę muszę kiedyś zaktualizować kopię ReleaseIt na CodePlex:

http://releaseit.codeplex.com/

Proste XCopy dla ASP.NET. Spakuj go, sftp na serwer, wypakuj do właściwej lokalizacji. W przypadku pierwszego wdrożenia należy ręcznie skonfigurować usługi IIS

Odpowiadając na Twoje pytania:

1. XCopy
2. Ręcznie
3. W przypadku zasobów statycznych wdrażamy tylko zmieniony zasób.
   W przypadku bibliotek DLL wdrażamy zmienione strony DLL i ASPX.
4. Tak i tak.

Utrzymanie tego w ładnym i prostym stylu pozwoliło nam dotychczas zaoszczędzić wielu bólów głowy.

Używasz jakichś konkretnych narzędzi czy po prostu XCOPY? Jak jest spakowana aplikacja (ZIP, MSI, ...)?

Jako programista BuildMaster używam tego naturalnie. Wszystkie aplikacje są tworzone i pakowane w narzędziu jako artefakty, które są przechowywane wewnętrznie jako pliki ZIP.

Kiedy aplikacja jest wdrażana po raz pierwszy, jak skonfigurować pulę aplikacji i katalog wirtualny (czy tworzysz je ręcznie czy za pomocą jakiegoś narzędzia)?

Ręcznie - tworzymy kontrolę zmian w narzędziu, która przypomina nam dokładne kroki, które należy wykonać w przyszłych środowiskach, gdy aplikacja przechodzi przez środowiska testowe. Można to również zautomatyzować za pomocą prostego skryptu PowerShell, ale nie dodajemy zbyt często nowych aplikacji, więc równie łatwo jest poświęcić 1 minutę na ręczne utworzenie witryny.

Kiedy zmienia się zasób statyczny (CSS, JS lub plik obrazu), czy ponownie wdrażasz całą aplikację, czy tylko zmodyfikowany zasób? Co powiesz na zmianę strony zestawu / ASPX?

Domyślnie proces wdrażania artefaktów jest skonfigurowany w taki sposób, że tylko zmodyfikowane pliki są przesyłane na serwer docelowy - obejmuje to wszystko od plików CSS, plików JavaScript, stron ASPX i połączonych zestawów.

Czy śledzisz wszystkie wdrożone wersje dla danej aplikacji, a jeśli coś pójdzie nie tak, masz procedury przywracania aplikacji do poprzedniego znanego stanu roboczego?

Tak, BuildMaster zajmuje się tym wszystkim za nas. Przywracanie jest w większości tak proste, jak ponowne wykonanie promocji starej kompilacji, ale czasami zmiany w bazie danych muszą zostać przywrócone ręcznie i może dojść do utraty danych. Podstawowy proces przywracania jest szczegółowo opisany tutaj: http://inedo.com/support/tutorials/performing-a-deployment-rollback-with-buildmaster

web ustawienia / projekty instalacji - dzięki czemu można je łatwo odinstalować, jeśli coś pójdzie nie tak

Unfold jest rozwiązaniem wdrożeniowym podobnym do Capistrano, które napisałem dla aplikacji .net. Tego używamy we wszystkich naszych projektach i jest to bardzo elastyczne rozwiązanie. Rozwiązuje większość typowych problemów z aplikacjami .net, jak wyjaśniono w tym wpisie na blogu Roba Conery'ego.

• ma dobre „domyślne” zachowanie, w tym sensie, że robi za Ciebie wiele standardowych rzeczy: pobieranie kodu z kontroli źródła, budowanie, tworzenie puli aplikacji, konfigurowanie IIS itp.
• wydania na podstawie zawartości kontroli źródła
• ma zaczepy do zadań , więc domyślne zachowanie można łatwo rozszerzyć lub zmienić
• to ma wycofanie
• to wszystko jest PowerShell , więc nie ma żadnych zewnętrznych zależności
• korzysta z usług zdalnych PowerShell, aby uzyskać dostęp do zdalnych maszyn

Oto wprowadzenie i kilka innych postów na blogu.

A więc odpowiadając na powyższe pytania:

• Jak jest spakowana aplikacja (ZIP, MSI, ...)?

  Git (lub inny scm) to domyślny sposób na pobranie aplikacji na komputer docelowy. Alternatywnie możesz wykonać lokalną kompilację i skopiować wynik przez połączenie zdalne Powereshell

• Kiedy aplikacja jest wdrażana po raz pierwszy, jak skonfigurować pulę aplikacji i katalog wirtualny (czy tworzysz je ręcznie czy za pomocą jakiegoś narzędzia)?

  Unfold konfiguruje pulę aplikacji i aplikację witryny internetowej przy użyciu modułu WebAdministration programu PowerShell. Pozwala nam (i Tobie) modyfikować dowolny aspekt puli aplikacji lub witryny internetowej

• Kiedy zmienia się zasób statyczny (CSS, JS lub plik obrazu), czy ponownie wdrażasz całą aplikację, czy tylko zmodyfikowany zasób? Co powiesz na zmianę strony zestawu / ASPX?

  Tak, rozwiń to, każde wdrożenie jest instalowane obok innych. W ten sposób możemy łatwo wycofać się, gdy coś pójdzie nie tak. Pozwala nam również łatwo prześledzić wstecz wdrożoną wersję do wersji kontroli źródła.

• Czy śledzisz wszystkie wdrożone wersje dla danej aplikacji?

  Tak, rozwiń zachowuje stare wersje. Nie wszystkie wersje, ale kilka wersji. To sprawia, że ​​wycofanie się jest prawie trywialne.

Poprawialiśmy nasz proces wydawania przez ostatni rok i teraz mamy to w porządku. Używam Jenkinsa do zarządzania wszystkimi naszymi automatycznymi kompilacjami i wydaniami, ale jestem pewien, że możesz użyć TeamCity lub CruiseControl.

Po sprawdzeniu nasza „normalna” kompilacja wykonuje następujące czynności:

• Jenkins wykonuje aktualizację SVN, aby pobrać najnowszą wersję kodu
• Przywracanie pakietu NuGet jest wykonywane w naszym własnym lokalnym repozytorium NuGet
• Aplikacja jest kompilowana przy użyciu programu MsBuild. Konfiguracja tego jest przygodą, ponieważ musisz zainstalować poprawną MsBuild, a następnie biblioteki DLL ASP.NET i MVC w polu kompilacji. (Na marginesie, kiedy miałem<MvcBuildViews>true</MvcBuildViews> do moich plików .csproj, aby skompilować widoki, msbuild był losowo zawieszany, więc musiałem go wyłączyć)
• Po skompilowaniu kodu uruchamiane są testy jednostkowe (używam do tego nunit, ale możesz użyć wszystkiego, co chcesz)
• Jeśli wszystkie testy jednostkowe zakończą się pomyślnie, zatrzymuję pulę aplikacji IIS, wdrażam aplikację lokalnie (wystarczy kilka podstawowych poleceń XCOPY w celu skopiowania niezbędnych plików), a następnie ponownie uruchamiam IIS (miałem problemy z plikami blokującymi IIS i to rozwiązane to)
• Mam oddzielne pliki web.config dla każdego środowiska; dev, uat, prod. (Próbowałem używać rzeczy do transformacji sieci z niewielkim sukcesem). Zatem odpowiedni plik web.config jest również kopiowany w poprzek
• Następnie używam PhantomJS do wykonania kilku testów interfejsu użytkownika. Wykonuje również kilka zrzutów ekranu w różnych rozdzielczościach (telefon komórkowy, komputer stacjonarny) i oznacza każdy zrzut ekranu z pewnymi informacjami (tytuł strony, rozdzielczość). Jenkins ma świetne wsparcie dla obsługi tych zrzutów ekranu i są one zapisywane jako część kompilacji
• Po pomyślnym przejściu testów interfejsu użytkownika integracji kompilacja zakończyła się pomyślnie

Jeśli ktoś kliknie „Wdróż w UAT”:

• Jeśli ostatnia kompilacja się powiodła, Jenkins dokonuje kolejnej aktualizacji SVN
• Aplikacja jest kompilowana przy użyciu konfiguracji RELEASE
• Tworzony jest katalog „www” i aplikacja jest do niego kopiowana
• Następnie używam winscp do synchronizacji systemu plików między polem kompilacji a UAT
• Wysyłam żądanie HTTP do serwera UAT i upewniam się, że otrzymam 200
• Ta wersja jest oznaczona w SVN jako UAT-data i godzina
• Jeśli zaszliśmy tak daleko, kompilacja się powiodła!

Kiedy klikniemy „Wdróż do produktu”:

• Użytkownik wybiera utworzony wcześniej tag UAT
• Znacznik jest „przełączony” na
• Kod jest kompilowany i synchronizowany z serwerem Prod
• Żądanie HTTP do serwera Prod
• Ta wersja jest oznaczona w SVN jako Prod-datetime
• Wydanie jest spakowane i przechowywane

Pełna kompilacja do produkcji zajmuje około 30 sekund, z czego jestem bardzo, bardzo zadowolony.

Zalety tego rozwiązania:

• To jest szybkie
• Testy jednostkowe powinny wychwytywać błędy logiczne
• Kiedy błąd interfejsu użytkownika trafi do produkcji, zrzuty ekranu pokażą, jaka wersja # spowodowała ten błąd
• UAT i Prod są zsynchronizowane
• Jenkins pokazuje wspaniałą historię wydań dla UAT i Prod wraz ze wszystkimi komunikatami o zmianach
• Wersje UAT i Prod są oznaczane automatycznie
• Możesz zobaczyć, kiedy wydano wydania i kto je zrobił

Główne wady tego rozwiązania to:

• Za każdym razem, gdy robisz wydanie na Prod, musisz zrobić wydanie na UAT. Podjęliśmy to świadomą decyzję, ponieważ chcieliśmy zawsze mieć pewność, że UAT jest zawsze na bieżąco z wersją Prod. Mimo to to ból.
• Wokół jest sporo plików konfiguracyjnych. Próbowałem mieć to wszystko w Jenkins, ale w ramach tego procesu potrzebnych jest kilka plików wsadowych. (Te również są rejestrowane).
• Skrypty aktualizacji i obniżenia wersji bazy danych są częścią aplikacji i są uruchamiane podczas jej uruchamiania. Działa (w większości), ale jest to uciążliwe.

Bardzo chciałbym usłyszeć inne możliwe ulepszenia!

W 2009 roku, skąd pochodzi ta odpowiedź, używaliśmy CruiseControl.net do naszych kompilacji Continuous Integration, które również wyświetlały Release Media.

Stamtąd użyliśmy oprogramowania Smart Sync do porównania z serwerem produkcyjnym, który był poza pulą o zrównoważonym obciążeniu, i przenieśliśmy zmiany w górę.

Wreszcie, po sprawdzeniu wersji, uruchomiliśmy skrypt DOS, który używał głównie RoboCopy do synchronizacji kodu z serwerami na żywo, zatrzymując / uruchamiając IIS na bieżąco.

W ostatniej firmie, dla której pracowałem, wdrażaliśmy za pomocą pliku wsadowego rSync, aby przesłać tylko zmiany od ostatniego załadowania. Piękno rSync polega na tym, że możesz dodawać listy wykluczeń, aby wykluczyć określone pliki lub wzorce nazw plików. Na przykład wykluczenie wszystkich naszych plików .cs, plików rozwiązań i projektów jest naprawdę łatwe.

Używaliśmy TortoiseSVN do kontroli wersji, więc miło było móc napisać kilka poleceń SVN, aby wykonać następujące czynności:

• Po pierwsze, sprawdź, czy użytkownik ma najnowszą wersję. Jeśli nie, poproś ich o aktualizację lub uruchom aktualizację od razu.
• Pobierz plik tekstowy z serwera o nazwie „synclog.txt”, który zawiera szczegółowe informacje o tym, kim jest użytkownik SVN, jaki numer wersji przesyła oraz datę i godzinę przesłania. Dołącz nowy wiersz dla bieżącego przesyłania, a następnie wyślij go z powrotem na serwer wraz ze zmienionymi plikami. To sprawia, że ​​niezwykle łatwo jest dowiedzieć się, do której wersji witryny należy wrócić, jeśli nie istnieje szansa, że ​​przesłanie spowoduje problemy.

Oprócz tego istnieje drugi plik wsadowy, który sprawdza tylko różnice między plikami na serwerze rzeczywistym. Może to uwydatnić częsty problem polegający na tym, że ktoś przesyła, ale nie przekazuje zmian do SVN. W połączeniu z wyżej wymienionym dziennikiem synchronizacji mogliśmy dowiedzieć się, kto był prawdopodobnym winowajcą i poprosić go o wykonanie swojej pracy.

I wreszcie, rSync umożliwia wykonanie kopii zapasowej plików, które zostały zastąpione podczas przesyłania. Poprosiliśmy o przeniesienie ich do folderu kopii zapasowej. Jeśli więc nagle zdasz sobie sprawę, że niektóre pliki nie powinny zostać nadpisane, możesz znaleźć ostatnią wersję kopii zapasowej każdego pliku w tym folderze.

Chociaż rozwiązanie wydawało się trochę niezgrabne w tamtym czasie, od tamtej pory doceniłem je znacznie bardziej podczas pracy w środowiskach, w których metoda przesyłania jest o wiele mniej elegancka lub łatwa (na przykład zdalny pulpit, skopiuj i wklej całą witrynę). .

Zalecałbym NIE tylko zastępowanie istniejących plików aplikacji, ale zamiast tego utworzenie katalogu według wersji i ponowne wskazanie aplikacji IIS na nową ścieżkę. Ma to kilka zalet:

• W razie potrzeby można szybko przywrócić
• Nie ma potrzeby zatrzymywania usług IIS ani puli aplikacji, aby uniknąć problemów z blokowaniem
• Brak ryzyka, że ​​stare pliki powodują problemy
• Mniej więcej zero przestojów (zwykle tylko przerwa przy inicjalizacji nowej domeny aplikacji)

Jedynym problemem, jaki mieliśmy, jest buforowanie zasobów, jeśli nie uruchomisz ponownie puli aplikacji i nie polegasz na automatycznym przełączaniu domeny aplikacji.