Wdrażanie określonej kompilacji

Autor Jason Lewandowski

Pobierz plik PDF

W tym temacie opisano sposób wdrażania pakietów sieci Web 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ęść szeregu samouczków opartych na wymaganiach dotyczących wdrażania w przedsiębiorstwie fikcyjnej firmy o nazwie Fabrikam, Inc. W tej serii samouczków jest stosowane—przykładowe rozwiązanie—do reprezentowania aplikacji sieci Web, które marealistyczny poziom 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 tym samouczku jest oparta na rozłożeniu pliku projektu dzielonego opisanym w artykule Omówienie pliku projektu, w którym proces kompilacji i wdrożenia jest kontrolowany przez dwa pliki—projektu, zawierający instrukcje kompilacji, które mają zastosowanie do każdego środowiska docelowego, oraz jeden zawierający ustawienia kompilacji i wdrożenia specyficznego dla środowiska. W czasie kompilacji plik projektu specyficzny dla środowiska jest scalany z plikiem projektu Environment-niezależny od w celu utworzenia kompletnego zestawu instrukcji kompilacji.

Przegląd zadania

Do tej pory tematy w tym zestawie samouczków koncentrują się na sposobach kompilowania, pakowania i wdrażania aplikacji sieci Web i baz danych w ramach procesu pojedynczego kroku lub zautomatyzowanego. Jednak w niektórych typowych scenariuszach warto wybrać zasoby wdrażane z listy kompilacji w folderze docelowym. Innymi słowy, Najnowsza kompilacja może nie być kompilacją, którą chcesz wdrożyć.

Zapoznaj się z scenariuszem ciągłej integracji (CI) opisanym w poprzednim temacie Tworzenie definicji kompilacji, która obsługuje wdrażanie. Utworzono definicję kompilacji w Team Foundation Server (TFS) 2010. Za każdym razem, gdy Deweloper sprawdza kod w programie TFS, Kompilacja zespołu kompiluje kod, tworzy pakiety sieci Web i skryptów bazy danych jako część 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 TFS będzie utrzymywać określoną liczbę wcześniejszych kompilacji.

Teraz Załóżmy, że wykonano testy weryfikacyjne i sprawdzanie poprawności dla jednego z tych kompilacji w środowisku testowym i wszystko jest gotowe do wdrożenia aplikacji w środowisku przejściowym. W międzyczasie deweloperzy mogli zaewidencjonować nowy kod. Nie chcesz ponownie skompilować rozwiązania i wdrożyć go w środowisku przejściowym, a nie chcesz wdrożyć najnowszej kompilacji w środowisku przejściowym. Zamiast tego należy wdrożyć konkretną kompilację, która została zweryfikowana i sprawdzona na serwerach testowych.

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

Zastępowanie właściwości OutputRoot

W przykładowym rozwiązaniuplik Publish. proj deklaruje właściwość o nazwie OutputRoot. Jak sugeruje nazwa, jest to folder główny, który zawiera wszystkie elementy generowane przez proces kompilacji. W pliku Publish. proj można zobaczyć, że właściwość OutputRoot odnosi się do lokalizacji głównej dla wszystkich zasobów wdrożenia.

Note

OutputRoot jest często używaną nazwą właściwości. Pliki C# projektu wizualizacji 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 sieci Web i skrypty bazy danych z innej—lokalizacji, takiej jak dane wyjściowe poprzedniej kompilacji—TFS, wystarczy przesłonić 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 wiersza polecenia, możesz określić wartość dla OutputRoot jako argument wiersza polecenia:

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

W tej sytuacji warto również pominąć cel— kompilacji , ale nie ma miejsca na kompilowanie rozwiązania, jeśli nie planujesz użyć danych wyjściowych kompilacji. Można to zrobić, określając cele, 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 kolejką kompilują uprawnienia do wyzwalania wdrożenia 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 tym przypadku nie chcesz, aby definicja kompilacji mogła w rzeczywistości kompilować—wszystkie elementy, które mają wykonać logikę wdrożenia w pliku projektu niestandardowego. Plik Publish. proj zawiera logikę warunkową, która pomija miejsce docelowe kompilacji , jeśli plik jest uruchomiony w kompilacji zespołowej. Robi to poprzez ocenę wbudowanej właściwości BuildingInTeamBuild , która jest automatycznie ustawiana na true , jeśli plik projektu jest uruchamiany 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, aby wyzwolić wdrożenie ręcznie

  1. 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.

  2. Na karcie Ogólne nadaj definicji kompilacji nazwę (na przykład DeployToStaging) i opcjonalny opis.

  3. Na karcie wyzwalacz wybierz pozycję Ręczne — zaewidencjonowanie nie wyzwalają nowej kompilacji.

  4. Na karcie Ustawienia domyślne kompilacji w polu Kopiuj dane wyjściowe kompilacji do poniższego folderu drop wpisz ścieżkę Universal Naming Convention (UNC) folderu docelowego (na przykład \TFSBUILD\Drops).

  5. Na karcie proces na liście rozwijanej plik procesu kompilacji pozostaw wybraną opcję DefaultTemplate. XAML . Jest to jeden z domyślnych szablonów procesu kompilacji, które zostaną dodane do wszystkich nowych projektów zespołowych.

  6. W tabeli parametry procesu kompilacji kliknij w wierszu elementy do skompilowania , a następnie kliknij przycisk wielokropka .

  7. W oknie dialogowym elementy do skompilowania kliknij pozycję Dodaj.

  8. Z listy rozwijanej elementy typu wybierz pozycję pliki projektu programu MSBuild.

  9. Przejdź do lokalizacji niestandardowego pliku projektu, za pomocą którego kontrolujesz proces wdrażania, wybierz plik, a następnie kliknij przycisk OK.

  10. W oknie dialogowym elementy do skompilowania kliknij przycisk OK.

  11. W tabeli parametry procesu kompilacji rozwiń sekcję Zaawansowane .

  12. W wierszu argumenty programu MSBuild Określ lokalizację pliku projektu specyficznego dla środowiska i Dodaj symbol zastępczy dla lokalizacji folderu kompilacji:

    /p:TargetEnvPropsFile=EnvConfig\Env-Stage.proj;
    OutputRoot=PLACEHOLDER
    

    Note

    Należy przesłonić wartość OutputRoot za każdym razem, gdy kolejkuje kompilację. Zostało to omówione w następnej procedurze.

  13. Kliknij przycisk Save (Zapisz).

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

Aby wdrożyć konkretną kompilację z definicji kompilacji

  1. W oknie Team Explorer kliknij prawym przyciskiem myszy definicję kompilacji, a następnie kliknij pozycję kolejka nowa kompilacja.

  2. W oknie dialogowym kompilacja kolejki na karcie Parametry rozwiń sekcję Zaawansowane .

  3. 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\
    

    Note

    Pamiętaj, aby uwzględnić końcowy ukośnik na końcu ścieżki do folderu kompilacji.

  4. Kliknij pozycję Kolejka.

Podczas kolejkowania kompilacji, plik projektu wdraża skrypty bazy danych i pakiety internetowe z folderu Drop Build określonego we właściwości OutputRoot .

Podsumowanie

W tym temacie opisano sposób publikowania zasobów wdrożenia, takich jak pakiety sieci Web i skrypty baz danych, z określonej poprzedniej kompilacji przy użyciu modelu wdrażania plików projektu rozdzielonego. Wyjaśniono, jak zastąpić właściwość OutputRoot i dołączać 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 w kolejkach, zobacz Queue a Build.