Zarządzanie cyklem życia aplikacji: od projektowania do produkcji

Autor: Jason Lee

W tym temacie pokazano, jak fikcyjna firma zarządza wdrażaniem aplikacji internetowej ASP.NET za pomocą środowisk testowych, przejściowych i produkcyjnych w ramach procesu ciągłego programowania. W tym temacie znajdują się linki do dalszych informacji i przewodników dotyczących wykonywania określonych zadań.

Ten temat został zaprojektowany w celu zapewnienia ogólnego przeglądu serii samouczków dotyczących wdrażania internetowego w przedsiębiorstwie. Nie martw się, jeśli nie znasz niektórych pojęć opisanych tutaj — samouczki, które są zgodne ze szczegółowymi informacjami na temat wszystkich tych zadań i technik.

Uwaga

Dla uproszczenia ten temat nie omawia aktualizowania baz danych w ramach procesu wdrażania. Jednak wprowadzanie przyrostowych aktualizacji funkcji baz danych jest wymaganiem wielu scenariuszy wdrażania w przedsiębiorstwie i możesz znaleźć wskazówki dotyczące tego, jak to zrobić w dalszej części tej serii samouczków. Aby uzyskać więcej informacji, zobacz Wdrażanie projektów bazy danych.

Omówienie

Przedstawiony tutaj proces wdrażania jest oparty na scenariuszu wdrażania Fabrikam, Inc. opisanym w temacie Enterprise Web Deployment: Scenario Overview (Wdrażanie w sieci Web w przedsiębiorstwie: omówienie scenariusza). Przed zapoznaniem się z tym tematem należy zapoznać się z omówieniem scenariusza. Zasadniczo scenariusz sprawdza, w jaki sposób organizacja zarządza wdrożeniem dość złożonej aplikacji internetowej, rozwiązania Contact Manager, za pomocą różnych faz w typowym środowisku przedsiębiorstwa.

Na wysokim poziomie rozwiązanie Contact Manager przechodzi przez te etapy w ramach procesu programowania i wdrażania:

  1. Deweloper sprawdza kod w programie Team Foundation Server (TFS) 2010.
  2. TfS kompiluje kod i uruchamia wszystkie testy jednostkowe skojarzone z projektem zespołowym.
  3. TfS wdraża rozwiązanie w środowisku testowym.
  4. Zespół deweloperów weryfikuje i weryfikuje rozwiązanie w środowisku testowym.
  5. Administrator środowiska przejściowego wykonuje wdrożenie "co jeśli" w środowisku przejściowym, aby ustalić, czy wdrożenie spowoduje jakiekolwiek problemy.
  6. Administrator środowiska przejściowego wykonuje wdrożenie na żywo w środowisku przejściowym.
  7. Rozwiązanie przechodzi testy akceptacyjne użytkowników w środowisku przejściowym.
  8. Pakiety wdrażania sieci Web są ręcznie importowane do środowiska produkcyjnego.

Te etapy stanowią część cyklu ciągłego programowania.

Te etapy stanowią część cyklu ciągłego programowania.

W praktyce proces jest nieco bardziej skomplikowany, jak zobaczysz, gdy przyjrzymy się poszczególnym etapom bardziej szczegółowo. Firma Fabrikam, Inc. używa innego podejścia do wdrażania dla każdego środowiska docelowego.

Firma Fabrikam, Inc. używa innego podejścia do wdrażania dla każdego środowiska docelowego.

W pozostałej części tego tematu przedstawiono następujące kluczowe etapy cyklu życia wdrażania:

  • Wymagania wstępne: jak należy skonfigurować infrastrukturę serwera przed wprowadzeniem logiki wdrażania.
  • Wstępne programowanie i wdrażanie: co należy zrobić przed wdrożeniem rozwiązania po raz pierwszy.
  • Wdrożenie do testowania: Jak spakować i wdrożyć zawartość w środowisku testowym automatycznie po zaewidencjonowaniu nowego kodu przez dewelopera.
  • Wdrażanie w środowisku przejściowym: jak wdrożyć określone kompilacje w środowisku przejściowym i jak wykonać wdrożenia "co jeśli", aby upewnić się, że wdrożenie nie spowoduje żadnych problemów.
  • Wdrażanie w środowisku produkcyjnym: jak zaimportować pakiety internetowe do środowiska produkcyjnego, gdy infrastruktura sieciowa uniemożliwia zdalne wdrażanie.

Wymagania wstępne

Pierwszym zadaniem w każdym scenariuszu wdrażania jest upewnienie się, że infrastruktura serwera spełnia wymagania narzędzi i technik wdrażania. W takim przypadku firma Fabrikam, Inc. skonfigurowała następującą infrastrukturę serwera:

Wstępne programowanie i wdrażanie

Zanim zespół deweloperów firmy Fabrikam, Inc. będzie mógł wdrożyć rozwiązanie Contact Manager po raz pierwszy, musi wykonać następujące zadania:

  • Utwórz nowy projekt zespołowy w programie TFS.
  • Utwórz pliki projektu Microsoft Build Engine (MSBuild), które zawierają logikę wdrażania.
  • Utwórz definicje kompilacji TFS, które wyzwalają procesy wdrażania.

Tworzenie nowego projektu zespołowego

Tworzenie logiki wdrażania

Matt Hink tworzy różne niestandardowe pliki projektów MSBuild przy użyciu metody podzielonego pliku projektu opisanego w temacie Understanding the Project File (Opis pliku projektu). Matt tworzy:

  • Plik projektu o nazwie Publish.proj , który uruchamia proces wdrażania. Ten plik zawiera obiekty docelowe programu MSBuild, które kompilują projekty w rozwiązaniu, tworzą pakiety internetowe i wdrażają pakiety w środowisku serwera docelowego.
  • Pliki projektów specyficzne dla środowiska o nazwach Env-Dev.proj i Env-Stage.proj. Zawierają one ustawienia specyficzne dla środowiska testowego i środowiska przejściowego, takie jak parametry połączenia, punkty końcowe usługi i szczegóły usługi zdalnej, które otrzymają pakiet internetowy. Aby uzyskać wskazówki dotyczące wybierania odpowiednich ustawień dla określonych środowisk docelowych, zobacz Konfigurowanie właściwości wdrożenia dla środowiska docelowego.

Aby uruchomić wdrożenie, użytkownik wykonuje plik Publish.proj przy użyciu programu MSBuild lub Team Build i określa lokalizację odpowiedniego pliku projektu specyficznego dla środowiska (Env-Dev.proj lub Env-Stage.proj) jako argument wiersza polecenia. Następnie plik Publish.proj importuje plik projektu specyficznego dla środowiska, aby utworzyć kompletny zestaw instrukcji publikowania dla każdego środowiska docelowego.

Uwaga

Sposób działania tych niestandardowych plików projektu jest niezależny od mechanizmu używanego do wywoływania programu MSBuild. Na przykład możesz bezpośrednio użyć wiersza polecenia MSBuild, zgodnie z opisem w temacie Understanding the Project File (Opis pliku projektu). Pliki projektu można uruchomić z pliku polecenia zgodnie z opisem w temacie Create and Run a Deployment Command File (Tworzenie i uruchamianie pliku polecenia wdrożenia). Alternatywnie możesz uruchomić pliki projektu z definicji kompilacji w programie TFS, zgodnie z opisem w temacie Tworzenie definicji kompilacji obsługującej wdrożenie.
W każdym przypadku wynik końcowy jest taki sam — program MSBuild wykonuje scalony plik projektu i wdraża rozwiązanie w środowisku docelowym. Zapewnia to dużą elastyczność w sposobie wyzwalania procesu publikowania.

Po utworzeniu niestandardowych plików projektu Matt dodaje je do folderu rozwiązania i sprawdza je w kontroli źródła.

Tworzenie definicji kompilacji

Jako ostateczne zadanie przygotowania Matt i Rob współpracują ze sobą, aby utworzyć trzy definicje kompilacji dla nowego projektu zespołowego:

  • DeployToTest. Spowoduje to skompilowanie rozwiązania Contact Manager i wdrożenie go w środowisku testowym za każdym razem, gdy nastąpi zaewidencjonowanie.
  • DeployToStaging. Spowoduje to wdrożenie zasobów z określonej poprzedniej kompilacji do środowiska przejściowego, gdy deweloper kolejkuje kompilację.
  • DeployToStaging-WhatIf. Wykonuje to wdrożenie "what if" w środowisku przejściowym, gdy deweloper kolejkuje kompilację.

Poniższe sekcje zawierają więcej szczegółów na temat każdej z tych definicji kompilacji.

Wdrażanie do testowania

Zespół programistyczny w firmie Fabrikam, Inc. utrzymuje środowiska testowe w celu przeprowadzania różnych działań związanych z testowaniem oprogramowania, takich jak weryfikacja i walidacja, testowanie użyteczności, testowanie zgodności oraz testowanie ad hoc lub eksploracyjne.

Zespół deweloperów utworzył definicję kompilacji w programie TFS o nazwie DeployToTest. Ta definicja kompilacji używa wyzwalacza ciągłej integracji, co oznacza, że proces kompilacji jest uruchamiany za każdym razem, gdy członek zespołu deweloperów Fabrikam, Inc. wykonuje ewidencjonowanie. Po wyzwoleniu kompilacji definicja kompilacji:

  • Skompiluj rozwiązanie ContactManager.sln. Z kolei kompiluje każdy projekt w ramach rozwiązania.
  • Uruchom wszystkie testy jednostkowe w strukturze folderów rozwiązania (jeśli rozwiązanie zostanie pomyślnie skompilowanych).
  • Uruchom niestandardowe pliki projektu, które kontrolują proces wdrażania (jeśli rozwiązanie zostanie pomyślnie skompilowanych i przejdzie wszystkie testy jednostkowe).

Wynikiem końcowym jest to, że jeśli rozwiązanie zostanie pomyślnie skompilowane i przejdzie testy jednostkowe, pakiety internetowe i inne zasoby wdrożenia zostaną wdrożone w środowisku testowym.

Wynikiem końcowym jest to, że jeśli rozwiązanie zostanie pomyślnie skompilowane i przejdzie testy jednostkowe, pakiety internetowe i inne zasoby wdrożenia zostaną wdrożone w środowisku testowym.

Jak działa proces wdrażania?

Definicja kompilacji DeployToTest dostarcza następujące argumenty do programu MSBuild:

/p:DeployOnBuild=true;DeployTarget=package;TargetEnvPropsFile=[path]\Env-Dev.proj

Właściwości DeployOnBuild=true i DeployTarget=package są używane, gdy kompilacja zespołu kompiluje projekty w ramach rozwiązania. Gdy projekt jest projektem aplikacji internetowej, te właściwości instruują program MSBuild, aby utworzyć pakiet wdrażania sieci Web dla projektu. Właściwość TargetEnvPropsFile informuje plik Publish.proj , gdzie można znaleźć plik projektu specyficznego dla środowiska do zaimportowania.

Uwaga

Aby uzyskać szczegółowy przewodnik dotyczący tworzenia definicji kompilacji w następujący sposób, zobacz Tworzenie definicji kompilacji obsługującej wdrożenie.

Plik Publish.proj zawiera obiekty docelowe, które kompilują każdy projekt w rozwiązaniu. Jednak obejmuje również logikę warunkową, która pomija te cele kompilacji, jeśli wykonujesz plik w kompilacji zespołu. Dzięki temu można korzystać z dodatkowych funkcji kompilacji, które oferuje kompilacja zespołu, na przykład możliwość uruchamiania testów jednostkowych. Jeśli kompilacja rozwiązania lub testy jednostkowe nie powiedzie się, plik Publish.proj nie zostanie wykonany, a aplikacja nie zostanie wdrożona.

Logika warunkowa jest realizowana przez ocenę właściwości BuildingInTeamBuild . Jest to właściwość MSBuild, która jest automatycznie ustawiana na wartość true podczas tworzenia projektów przy użyciu kompilacji zespołu.

Wdrażanie w środowisku przejściowym

Gdy kompilacja spełnia wszystkie wymagania zespołu deweloperów w środowisku testowym, zespół może chcieć wdrożyć tę samą kompilację w środowisku przejściowym. Środowiska przejściowe są zwykle skonfigurowane tak, aby odpowiadały charakterystykom środowiska produkcyjnego lub "na żywo", jak to możliwe, na przykład pod względem specyfikacji serwera, systemów operacyjnych i oprogramowania oraz konfiguracji sieci. Środowiska przejściowe są często używane do testowania obciążenia, testowania akceptacji użytkowników i szerszych przeglądów wewnętrznych. Kompilacje są wdrażane w środowisku przejściowym bezpośrednio z serwera kompilacji.

Kompilacje są wdrażane w środowisku przejściowym bezpośrednio z serwera kompilacji.

Definicje kompilacji używane do wdrażania rozwiązania w środowisku przejściowym , DeployToStaging-WhatIf i DeployToStaging mają następujące cechy:

  • W rzeczywistości nic nie budują. Gdy Rob wdraża rozwiązanie w środowisku przejściowym, chce wdrożyć konkretną, istniejącą kompilację, która została już zweryfikowana i zweryfikowana w środowisku testowym. Definicje kompilacji muszą po prostu uruchomić niestandardowe pliki projektu kontrolujące proces wdrażania.
  • Gdy Rob wyzwala kompilację, używa parametrów kompilacji do określenia, które kompilacja zawiera zasoby, które chce wdrożyć z serwera kompilacji.
  • Definicje kompilacji nie są wyzwalane automatycznie. Rob ręcznie kolejkuje kompilację, gdy chce wdrożyć rozwiązanie w środowisku przejściowym.

Jest to proces wysokiego poziomu wdrożenia w środowisku przejściowym:

  1. Administrator środowiska przejściowego Rob Walters tworzy kolejkę kompilacji przy użyciu definicji kompilacji DeployToStaging-WhatIf . Rob używa parametrów definicji kompilacji do określenia, która kompilacja ma zostać wdrożona.
  2. Definicja kompilacji DeployToStaging-WhatIf uruchamia niestandardowe pliki projektu w trybie "what if". Generuje to pliki dziennika tak, jakby Rob wykonywał wdrożenie na żywo, ale w rzeczywistości nie wprowadza żadnych zmian w środowisku docelowym.
  3. Rob przegląda pliki dziennika, aby ustalić wpływ wdrożenia w środowisku przejściowym. W szczególności Rob chce sprawdzić, co zostanie dodane, co zostanie zaktualizowane i co zostanie usunięte.
  4. Jeśli rob jest zadowolony, że wdrożenie nie wprowadzi żadnych niepożądanych zmian w istniejących zasobach lub danych, kolejkuje kompilację przy użyciu definicji kompilacji DeployToStaging .
  5. Definicja kompilacji DeployToStaging uruchamia niestandardowe pliki projektu. Te publikują zasoby wdrożenia na podstawowym serwerze internetowym w środowisku przejściowym.
  6. Kontroler programu Web Farm Framework (WFF) synchronizuje serwery internetowe w środowisku przejściowym. Dzięki temu aplikacja jest dostępna na wszystkich serwerach sieci Web w farmie serwerów.

Jak działa proces wdrażania?

Definicja kompilacji DeployToStaging dostarcza następujące argumenty do programu MSBuild:

/p:TargetEnvPropsFile=[path]\Env-Stage.proj;OutputRoot=[path to build folder]

Właściwość TargetEnvPropsFile informuje plik Publish.proj , gdzie można znaleźć plik projektu specyficznego dla środowiska do zaimportowania. Właściwość OutputRoot zastępuje wbudowaną wartość i wskazuje lokalizację folderu kompilacji zawierającego zasoby, które chcesz wdrożyć. Gdy Rob kolejkuje kompilację, używa karty Parametry , aby podać zaktualizowaną wartość właściwości OutputRoot .

Gdy Rob kolejkuje kompilację, używa karty Parametry, aby podać zaktualizowaną wartość właściwości OutputRoot.

Uwaga

Aby uzyskać więcej informacji na temat tworzenia definicji kompilacji w następujący sposób, zobacz Wdrażanie określonej kompilacji.

Definicja kompilacji DeployToStaging-WhatIf zawiera taką samą logikę wdrożenia, jak definicja kompilacji DeployToStaging . Zawiera jednak dodatkowy argument WhatIf=true:

/p:TargetEnvPropsFile=[path]\Env-Stage.proj;
   OutputRoot=[path to build folder];
   WhatIf=true

W pliku Publish.proj właściwość WhatIf wskazuje, że wszystkie zasoby wdrożenia powinny być publikowane w trybie "what if". Innymi słowy, pliki dziennika są generowane tak, jakby wdrożenie poszło do przodu, ale nic nie zostało rzeczywiście zmienione w środowisku docelowym. Pozwala to ocenić wpływ proponowanego wdrożenia — w szczególności to, co zostanie dodane, co zostanie zaktualizowane i co zostanie usunięte — zanim rzeczywiście wprowadzisz jakiekolwiek zmiany.

Uwaga

Aby uzyskać więcej informacji na temat konfigurowania wdrożeń "what if", zobacz Wykonywanie wdrożenia "What If".

Po wdrożeniu aplikacji na podstawowym serwerze internetowym w środowisku przejściowym program WFF automatycznie synchronizuje aplikację na wszystkich serwerach w farmie serwerów.

Uwaga

Aby uzyskać więcej informacji na temat konfigurowania serwera WFF do synchronizowania serwerów sieci Web, zobacz Tworzenie farmy serwerów za pomocą struktury farmy sieci Web.

Wdrażanie w środowisku produkcyjnym

Po zatwierdzeniu kompilacji w środowisku przejściowym zespół Fabrikam, Inc. może opublikować aplikację w środowisku produkcyjnym. Środowisko produkcyjne to miejsce, w którym aplikacja przechodzi "na żywo" i dociera do odbiorców docelowych użytkowników końcowych.

Środowisko produkcyjne znajduje się w sieci obwodowej dostępnej z Internetu. Jest to odizolowane od sieci wewnętrznej, która zawiera serwer kompilacji. Administrator środowiska produkcyjnego, Lisa Andrews, musi ręcznie skopiować pakiety wdrażania sieci Web z serwera kompilacji i zaimportować je do usług IIS na podstawowym produkcyjnym serwerze sieci Web.

Administrator środowiska produkcyjnego musi ręcznie skopiować pakiety wdrażania sieci Web z serwera kompilacji i zaimportować je do I S na podstawowym produkcyjnym serwerze internetowym.

Jest to proces wysokiego poziomu wdrożenia w środowisku produkcyjnym:

  1. Zespół deweloperów doradza Lisie, że kompilacja jest gotowa do wdrożenia w środowisku produkcyjnym. Zespół doradza Lisa o lokalizacji pakietów wdrażania sieci Web w folderze drop na serwerze kompilacji.
  2. Lisa zbiera pakiety internetowe z serwera kompilacji i kopiuje je do podstawowego serwera internetowego w środowisku produkcyjnym.
  3. Lisa używa Menedżera usług IIS do importowania i publikowania pakietów internetowych na podstawowym serwerze sieci Web.
  4. Kontroler WFF synchronizuje serwery internetowe w środowisku produkcyjnym. Dzięki temu aplikacja jest dostępna na wszystkich serwerach sieci Web w farmie serwerów.

Jak działa proces wdrażania?

Menedżer usług IIS zawiera Kreatora importowania pakietów aplikacji, który ułatwia publikowanie pakietów internetowych w witrynie internetowej usług IIS. Aby zapoznać się z przewodnikiem po sposobie wykonywania tej procedury, zobacz Ręczne instalowanie pakietów sieci Web.

Podsumowanie

W tym temacie przedstawiono ilustrację cyklu życia wdrażania dla typowej aplikacji internetowej w skali przedsiębiorstwa.

Ten temat stanowi część serii samouczków, które zawierają wskazówki dotyczące różnych aspektów wdrażania aplikacji internetowych. W praktyce istnieje wiele dodatkowych zadań i zagadnień na każdym etapie procesu wdrażania i nie jest możliwe pokrycie ich wszystkich w jednym przewodniku. Aby uzyskać więcej informacji, zapoznaj się z następującymi samouczkami: