Wdrażanie określonej kompilacji

Artykuł
07/13/2023

W tym temacie opisano sposób wdrażania pakietów internetowych i skryptów bazy danych z określonej poprzedniej kompilacji do nowego miejsca docelowego, takiego jak środowisko przejściowe lub produkcyjne.

Ten temat stanowi część serii samouczków opartych na wymaganiach dotyczących wdrażania przedsiębiorstwa fikcyjnej firmy o nazwie Fabrikam, Inc. W tej serii samouczków użyto przykładowego rozwiązania — rozwiązania Contact Manager — do reprezentowania aplikacji internetowej o realistycznym poziomie złożoności, w tym aplikacji ASP.NET MVC 3, usługi Windows Communication Foundation (WCF) i projektu bazy danych.

Metoda wdrażania w centrum tych samouczków opiera się na metodzie podzielonego pliku projektu opisanego w artykule Opis pliku projektu, w którym proces kompilacji i wdrażania jest kontrolowany przez dwa pliki projektu — jeden zawierający instrukcje kompilacji, które mają zastosowanie do każdego środowiska docelowego, oraz jeden zawierający ustawienia kompilacji i wdrażania specyficzne dla środowiska. W czasie kompilacji plik projektu specyficzny dla środowiska jest scalony z plikiem projektu niezależnego od środowiska w celu utworzenia pełnego zestawu instrukcji kompilacji.

Omówienie zadań

Do tej pory tematy w tym zestawie samouczków koncentrowały się na tworzeniu, pakowaniu i wdrażaniu aplikacji internetowych i baz danych w ramach pojedynczego lub zautomatyzowanego procesu. Jednak w niektórych typowych scenariuszach należy wybrać zasoby wdrażane z listy kompilacji w folderze upuszczania. Innymi słowy, najnowsza kompilacja może nie być kompilacją, którą chcesz wdrożyć.

Rozważmy scenariusz ciągłej integracji opisany w poprzednim temacie Tworzenie definicji kompilacji obsługującej wdrożenie. Utworzono definicję kompilacji w programie Team Foundation Server (TFS) 2010. Za każdym razem, gdy deweloper sprawdza kod w programie TFS, kompilacja zespołu będzie kompilować kod, tworzyć pakiety internetowe i skrypty bazy danych w ramach procesu kompilacji, uruchamiać wszystkie testy jednostkowe i wdrażać zasoby w środowisku testowym. W zależności od zasad przechowywania skonfigurowanych podczas tworzenia definicji kompilacji program TFS zachowa pewną liczbę poprzednich kompilacji.

W zależności od zasad przechowywania skonfigurowanych podczas tworzenia definicji kompilacji T F S zachowa określoną liczbę poprzednich kompilacji. =======

Teraz załóżmy, że przeprowadzono testy weryfikacji i walidacji względem jednej z tych kompilacji w środowisku testowym i możesz przystąpić do wdrażania aplikacji w środowisku przejściowym. W międzyczasie deweloperzy mogli zaewidencjonowali nowy kod. Nie chcesz ponownie kompilować rozwiązania i wdrażać go w środowisku przejściowym i nie chcesz wdrażać najnowszej kompilacji w środowisku przejściowym. Zamiast tego chcesz wdrożyć określoną kompilację zweryfikowaną i zweryfikowaną na serwerach testowych.

Aby to osiągnąć, należy poinformować Microsoft Build Engine (MSBuild), gdzie można znaleźć pakiety internetowe i skrypty bazy danych wygenerowane przez określoną kompilację.

Zastępowanie właściwości OutputRoot

W przykładowym rozwiązaniu plik Publish.proj deklaruje właściwość o nazwie OutputRoot. Jak sugeruje nazwa, jest to folder główny zawierający wszystko, co generuje proces kompilacji. W pliku Publish.proj widać, że właściwość OutputRoot odwołuje się do lokalizacji głównej dla wszystkich zasobów wdrożenia.

Uwaga

OutputRoot to powszechnie używana nazwa właściwości. Pliki projektów Visual C# i Visual Basic również deklarują tę właściwość do przechowywania lokalizacji głównej dla wszystkich danych wyjściowych kompilacji.

<PropertyGroup>
  <!--This is where the .deploymanifest file will be written to during a build-->    
  <_DbDeployManifestPath>
    $(OutputRoot)ContactManager.Database.deploymanifest
  </_DbDeployManifestPath>    
  
  <!-- The folder where the .zip and .cmd file will be located for 
                ContactManager.Mvc Web project -->
  <_ContactManagerDest>
    $(OutputRoot)_PublishedWebsites\ContactManager.Mvc_Package\
  </_ContactManagerDest>
  
  <!-- The folder where the .zip and .cmd file will be located for 
                ContactManager.Service Web project -->
   <_ContactManagerSvcDest>
    $(OutputRoot)_PublishedWebsites\ContactManager.Service_Package\
  </_ContactManagerSvcDest>
  
  <!-- ... -->
</PropertyGroup>

Jeśli chcesz, aby plik projektu wdrażał pakiety internetowe i skrypty bazy danych z innej lokalizacji — na przykład dane wyjściowe poprzedniej kompilacji TFS — wystarczy zastąpić właściwość OutputRoot . Należy ustawić wartość właściwości na odpowiedni folder kompilacji na serwerze kompilacji zespołu. Jeśli używasz programu MSBuild z poziomu wiersza polecenia, możesz określić wartość parametru OutputRoot jako argument wiersza polecenia:

msbuild.exe Publish.proj /p:TargetEnvPropsFile=EnvConfig\Env-Dev.proj 
  /p:OutputRoot=\\TFSBUILD\Drops\DeployToTest\DeployToTest_20120228.3\

W praktyce jednak warto pominąć cel kompilacji — nie ma sensu kompilować rozwiązania, jeśli nie planujesz używania danych wyjściowych kompilacji. Można to zrobić, określając obiekty docelowe, które mają zostać wykonane z wiersza polecenia:

msbuild.exe Publish.proj /p:TargetEnvPropsFile=EnvConfig\Env-Dev.proj 
  /p:OutputRoot=\\TFSBUILD\Drops\DeployToTest\DeployToTest_20120228.3\
  /target:GatherPackagesForPublishing;PublishDBPackages;PublishWebPackages

Jednak w większości przypadków należy utworzyć logikę wdrożenia w definicji kompilacji tfS. Dzięki temu użytkownicy z uprawnieniami do kompilacji kolejki mogą wyzwalać wdrożenie z dowolnej instalacji programu Visual Studio z połączeniem z serwerem TFS.

Tworzenie definicji kompilacji w celu wdrożenia określonych kompilacji

W następnej procedurze opisano sposób tworzenia definicji kompilacji, która umożliwia użytkownikom wyzwalanie wdrożeń w środowisku przejściowym za pomocą jednego polecenia.

W takim przypadku nie chcesz, aby definicja kompilacji w rzeczywistości tworzyła wszystko — wystarczy, że ma ona wykonać logikę wdrażania w niestandardowym pliku projektu. Plik Publish.proj zawiera logikę warunkową, która pomija element docelowy kompilacji , jeśli plik jest uruchomiony w kompilacji zespołu. Robi to, oceniając wbudowaną właściwość BuildingInTeamBuild , która jest automatycznie ustawiona na wartość true , jeśli uruchomisz plik projektu w kompilacji zespołu. W związku z tym można pominąć proces kompilacji i po prostu uruchomić plik projektu, aby wdrożyć istniejącą kompilację.

Aby utworzyć definicję kompilacji w celu ręcznego wyzwolenia wdrożenia

W programie Visual Studio 2010 w oknie Team Explorer rozwiń węzeł projektu zespołowego, kliknij prawym przyciskiem myszy pozycję Kompilacje, a następnie kliknij pozycję Nowa definicja kompilacji.
Na karcie Ogólne nadaj definicji kompilacji nazwę (na przykład DeployToStaging) i opcjonalny opis.
Na karcie Wyzwalacz wybierz pozycję Ręczne — zaewidencjonowanie nie wyzwala nowej kompilacji.
Na karcie Wartości domyślne kompilacji w polu Kopiuj dane wyjściowe kompilacji do następującego folderu upuszczania wpisz ścieżkę Universal Naming Convention (UNC) folderu upuszczania (na przykład \TFSBUILD\Drop).

$Na karcie Wartości domyślne kompilacji w polu Kopiuj dane wyjściowe kompilacji do następującego folderu upuszczania wpisz ścieżkę Universal Naming Convention (U N C) folderu upuszczania (na przykład \TFSBUILD\Drop).$
Na karcie Proces na liście rozwijanej Plik procesu kompilacji pozostaw zaznaczoną pozycję DefaultTemplate.xaml . Jest to jeden z domyślnych szablonów procesów kompilacji, które są dodawane do wszystkich nowych projektów zespołowych.
W tabeli Parametry procesu kompilacji kliknij wiersz Items to Build (Elementy do kompilacji ), a następnie kliknij przycisk wielokropka .
W oknie dialogowym Elementy do kompilacji kliknij przycisk Dodaj.
Na liście rozwijanej Elementy typu wybierz pozycję Pliki projektu MSBuild.
Przejdź do lokalizacji niestandardowego pliku projektu, za pomocą którego kontrolujesz proces wdrażania, wybierz plik, a następnie kliknij przycisk OK.
W oknie dialogowym Elementy do kompilacji kliknij przycisk OK.
W tabeli Parametry procesu kompilacji rozwiń sekcję Zaawansowane .
W wierszu Argumenty msBuild określ lokalizację pliku projektu specyficznego dla środowiska i dodaj symbol zastępczy lokalizacji folderu kompilacji:
```
/p:TargetEnvPropsFile=EnvConfig\Env-Stage.proj;
OutputRoot=PLACEHOLDER
```
Uwaga

Należy zastąpić wartość OutputRoot za każdym razem, gdy kolejkujesz kompilację. Jest to omówione w następnej procedurze.
Kliknij pozycję Zapisz.

Po wyzwoleniu kompilacji należy zaktualizować właściwość OutputRoot , aby wskazywała kompilację, którą chcesz wdrożyć.

Aby wdrożyć określoną kompilację na podstawie definicji kompilacji

W oknie Team Explorer kliknij prawym przyciskiem myszy definicję kompilacji, a następnie kliknij pozycję Kolejka nowa kompilacja.
W oknie dialogowym Kompilacja kolejki na karcie Parametry rozwiń sekcję Zaawansowane .
W wierszu Argumenty programu MSBuild zastąp wartość właściwości OutputRoot lokalizacją folderu kompilacji. Na przykład:
```
/p:TargetEnvPropsFile=EnvConfig\Env-Stage.proj;
   OutputRoot=\\TFSBUILD\Drops\DeployToTest\DeployToTest_20120228.3\
```
Uwaga

Pamiętaj o dołączeniu końcowego ukośnika na końcu ścieżki do folderu kompilacji.
Kliknij pozycję Kolejka.

Po kolejce kompilacji plik projektu wdroży skrypty bazy danych i pakiety internetowe z folderu upuszczania kompilacji określonego we właściwości OutputRoot .

Podsumowanie

W tym temacie opisano sposób publikowania zasobów wdrażania, takich jak pakiety internetowe i skrypty bazy danych, z określonej poprzedniej kompilacji przy użyciu modelu wdrażania podzielonego pliku projektu. Wyjaśniono, jak zastąpić właściwość OutputRoot i jak dołączyć logikę wdrażania do definicji kompilacji TFS.

Dalsze informacje

Aby uzyskać więcej informacji na temat tworzenia definicji kompilacji, zobacz Tworzenie podstawowej definicji kompilacji i Definiowanie procesu kompilacji. Aby uzyskać więcej wskazówek dotyczących kompilacji kolejkowania, zobacz Kolejkowanie kompilacji.

Wstecz Dalej