Ćwiczenie — podwyższanie poziomu do etapu testowego

Ukończone

Potok wydania nadal ma dwa etapy, ale są teraz inne niż wcześniej. Etapy to Build and Dev. Każda zmiana wypychana do usługi GitHub wyzwala etap kompilacji do uruchomienia. Etap deweloperski jest uruchamiany tylko wtedy, gdy zmiana znajduje się w gałęzi wydania . W tym miejscu dodasz etap testowy do potoku.

Przypomnij sobie, że zespół zdecydował się użyć zaplanowanego wyzwalacza w celu podwyższenia poziomu kompilacji z etapu deweloperskiego do etapu testowego o godzinie 3 rano. Aby skonfigurować zaplanowany wyzwalacz:

• Zdefiniuj harmonogram w konfiguracji kompilacji.
• Zdefiniuj etap testowy, który zawiera warunek, który uruchamia etap tylko wtedy, gdy przyczyna kompilacji jest oznaczona jako Schedule.

W celach szkoleniowych zdefiniujesz harmonogram, ale zezwalasz na przejście kompilacji bezpośrednio z tworzenia do testowania. Ta konfiguracja pozwala uniknąć konieczności oczekiwania na wyzwolenie harmonogramu. Po ukończeniu tego modułu spróbuj eksperymentować z różnymi wyrażeniami cron, aby uruchomić etap testowy tylko w zaplanowanym czasie.

Podwyższanie poziomu zmian do etapu testowego

W tym miejscu zmodyfikujesz konfigurację potoku, aby wdrożyć kompilację na etapie testowania.

1. W programie Visual Studio Code zmodyfikuj plik azure-pipelines.yml w następujący sposób:

   trigger:
   - '*'
   
   variables:
     buildConfiguration: 'Release'
     releaseBranchName: 'release'
   
   schedules:
   - cron: '0 3 * * *'
     displayName: 'Deploy every day at 3 A.M.'
     branches:
       include:
       - release
     always: false 
   
   stages:
   - stage: 'Build'
     displayName: 'Build the web application'
     jobs: 
     - job: 'Build'
       displayName: 'Build job'
       pool:
         vmImage: 'ubuntu-20.04'
         demands:
         - npm
   
       variables:
         wwwrootDir: 'Tailspin.SpaceGame.Web/wwwroot'
         dotnetSdkVersion: '6.x'
   
       steps:
       - task: UseDotNet@2
         displayName: 'Use .NET SDK $(dotnetSdkVersion)'
         inputs:
           version: '$(dotnetSdkVersion)'
   
       - task: Npm@1
         displayName: 'Run npm install'
         inputs:
           verbose: false
   
       - script: './node_modules/.bin/node-sass $(wwwrootDir) --output $(wwwrootDir)'
         displayName: 'Compile Sass assets'
   
       - task: gulp@1
         displayName: 'Run gulp tasks'
   
       - script: 'echo "$(Build.DefinitionName), $(Build.BuildId), $(Build.BuildNumber)" > buildinfo.txt'
         displayName: 'Write build info'
         workingDirectory: $(wwwrootDir)
   
       - task: DotNetCoreCLI@2
         displayName: 'Restore project dependencies'
         inputs:
           command: 'restore'
           projects: '**/*.csproj'
   
       - task: DotNetCoreCLI@2
         displayName: 'Build the project - $(buildConfiguration)'
         inputs:
           command: 'build'
           arguments: '--no-restore --configuration $(buildConfiguration)'
           projects: '**/*.csproj'
   
       - task: DotNetCoreCLI@2
         displayName: 'Publish the project - $(buildConfiguration)'
         inputs:
           command: 'publish'
           projects: '**/*.csproj'
           publishWebProjects: false
           arguments: '--no-build --configuration $(buildConfiguration) --output $(Build.ArtifactStagingDirectory)/$(buildConfiguration)'
           zipAfterPublish: true
   
       - publish: '$(Build.ArtifactStagingDirectory)'
         artifact: drop
   
   - stage: 'Dev'
     displayName: 'Deploy to the dev environment'
     dependsOn: Build
     condition: |
       and
       (
         succeeded(),
         eq(variables['Build.SourceBranchName'], variables['releaseBranchName'])
       )
     jobs:
     - deployment: Deploy
       pool:
         vmImage: 'ubuntu-20.04'
       environment: dev
       variables:
       - group: Release
       strategy:
         runOnce:
           deploy:
             steps:
             - download: current
               artifact: drop
             - task: AzureWebApp@1
               displayName: 'Azure App Service Deploy: website'
               inputs:
                 azureSubscription: 'Resource Manager - Tailspin - Space Game'
                 appName: '$(WebAppNameDev)'
                 package: '$(Pipeline.Workspace)/drop/$(buildConfiguration)/*.zip'
   
   - stage: 'Test'
     displayName: 'Deploy to the test environment'
     dependsOn: Dev
     #condition: eq(variables['Build.Reason'], 'Schedule')
     jobs:
     - deployment: Deploy
       pool:
         vmImage: 'ubuntu-20.04'
       environment: test
       variables:
       - group: 'Release'
       strategy:
         runOnce:
           deploy:
             steps:
             - download: current
               artifact: drop
             - task: AzureWebApp@1
               displayName: 'Azure App Service Deploy: website'
               inputs:
                 azureSubscription: 'Resource Manager - Tailspin - Space Game'
                 appName: '$(WebAppNameTest)'
                 package: '$(Pipeline.Workspace)/drop/$(buildConfiguration)/*.zip'
   

   Sekcja schedules definiuje jedno wyrażenie cron. W konfiguracji można zdefiniować więcej niż jedno wyrażenie. Wyrażenie wyzwala potok do uruchomienia względem gałęzi wydania o godzinie 3:00 każdego dnia. Flaga always jest ustawiona tak false , aby potok był uruchamiany tylko wtedy, gdy gałąź wydania zawiera zmiany z poprzedniego uruchomienia.

   Etap Test definiuje warunek, który uruchamia etap tylko wtedy, gdy przyczyna kompilacji jest Schedulerówna . (Wbudowana zmienna Build.Reason definiuje przyczynę kompilacji). Jeśli ten warunek ma wartość false, etap zostanie pominięty, ale poprzednie etapy będą nadal uruchamiane.

   Uwaga

   Ten warunek jest wyświetlany w celach szkoleniowych. Oznacza to włączenie zmiany z tworzenia i testowania bez oczekiwania na wyzwolenie harmonogramu.

2. Z poziomu zintegrowanego terminalu do indeksu dodaj plik azure-pipelines.yml. Następnie zatwierdź zmianę i wypchnij ją do usługi GitHub.

   Napiwek

   Przed uruchomieniem tych poleceń usługi Git zapisz plik azure-pipelines.yml.

   git add azure-pipelines.yml
   git commit -m "Deploy to the Test stage"
   git push origin release
   

3. W usłudze Azure Pipelines przejdź do kompilacji. Śledzenie kompilacji podczas jej uruchamiania.

4. Po zakończeniu kompilacji, aby powrócić do strony podsumowania, wybierz przycisk Wstecz.

   

   Zobaczysz, że wdrożenie zakończyło się pomyślnie.

5. W przeglądarce internetowej przejdź do adresu URL skojarzonego z wystąpieniem usługi App Service dla środowiska testowego .

   Jeśli nadal masz otwartą kartę przeglądarki, odśwież stronę. Jeśli nie pamiętasz adresu URL, znajdź go w witrynie Azure Portal na stronie szczegółów usługi App Service.

   Zobaczysz, że witryna internetowa Space Game jest wdrożona w usłudze App Service i jest uruchomiona.

   

6. Opcjonalnie w usłudze Azure Pipelines wybierz pozycję Środowiska. Następnie wybierz środowisko testowe.

   Usługa Azure Pipelines rejestruje historię wdrażania. W historii można śledzić zmiany w środowisku z powrotem do zatwierdzeń kodu i elementów roboczych.

   

Andy i Mara dodają etap testowy do potoku. Pokazują wyniki Amita.

Amita: Podoba mi się, że zmiany są kompilowane i wdrażane, abym mógł je przetestować każdego ranka. Ale nie widzę, jak mogę kontrolować, kiedy zmiany docierają do przejściowego.

Mara: Tak, wdrażanie za pomocą automatyzacji oszczędza dużo czasu. Pamiętaj, że uwzględniliśmy tylko zaplanowany wyzwalacz. Dodajmy dla Ciebie zatwierdzenie wydania podczas konfigurowania środowiska przejściowego dla tima. W ten sposób zmiany są przenoszone do przemieszczania tylko wtedy, gdy wszystko będzie gotowe.