Упражнение. Повышение до этапа тестирования

Завершено

Конвейер выпуска по-прежнему имеет два этапа, но теперь они отличаются от ранее. Этапы: сборка и разработка. Все изменения, которые вы отправляете в GitHub, активирует этап сборки для запуска. Этап разработки выполняется только в том случае, если изменение находится в ветви выпуска . Здесь вы добавите этап тестирования в конвейер.

Напомним, что команда решила использовать запланированный триггер для продвижения сборки с этапа разработки на этап тестирования в 3 часа каждое утро. Чтобы настроить запланированный триггер, выполните следующие действия.

  • Определите расписание в конфигурации сборки.
  • Определите этап Тестирования, который включает в себя условие запуска этапа, только если причина сборки помечена как Schedule.

В целях обучения здесь вы определяете расписание, но позволяет сборке переходить непосредственно от разработки к тестированию. Эта настройка позволяет избежать необходимости ждать активации расписания. После завершения этого модуля поэкспериментируйте с различными выражениями cron. чтобы запускать этап Тестирования строго по расписанию.

Повышение уровня изменений на этапе тестирования

Здесь вы измените конфигурацию конвейера, чтобы развернуть сборку на этапе тестирования .

  1. В Visual Studio Code измените azure-pipelines.yml следующим образом:

    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'
    

    В schedules разделе определяется одно выражение cron. В конфигурации можно определить несколько выражений. Это выражение запускает конвейер для выполнения в ветви выпуска в 3 часа утра каждый день. Флаг always установлен false таким образом, чтобы конвейер выполнялся только в том случае, если ветвь выпуска содержит изменения с предыдущего запуска.

    Этап Test определяет условие, которое запускает этап только в том случае, если причина сборки Scheduleравна. (Встроенная переменная Build.Reason определяет причину сборки.) Если это условие равно false, этап пропускается, но предыдущие этапы продолжают выполняться.

    Примечание.

    Это условие отображается для целей обучения. Он закомментирован, чтобы включить изменение, чтобы перейти от разработки к тестированию , не ожидая активации расписания.

  2. В интегрированном терминале добавьте azure-pipelines.yml из встроенного терминала. Затем зафиксируйте изменение и отправьте его в GitHub.

    Совет

    Перед выполнением этих команд Git сохраните azure-pipelines.yml.

    git add azure-pipelines.yml
    git commit -m "Deploy to the Test stage"
    git push origin release
    
  3. В Azure Pipelines перейдите к сборке. Трассировка сборки при выполнении.

  4. После завершения сборки, чтобы вернуться на страницу сводки, нажмите кнопку "Назад".

    A screenshot of Azure Pipelines showing three completed stages: Build, Dev, and Test.

    Вы видите, что развертывание успешно завершено.

  5. В веб-браузере перейдите по URL-адресу, связанному с экземпляром Служба приложений для тестовой среды.

    Если у вас по-прежнему открыта вкладка браузера, обновите страницу. Если вы не помните URL-адрес, найдите его в портал Azure, на странице сведений о Служба приложений.

    Вы видите, что веб-сайт Space Game развернут в Служба приложений, и он работает.

    A screenshot of a web browser showing the Space Game website in the Test environment.

  6. В качестве дополнительного шага в Azure Pipelines выберите "Среды". Затем выберите тестовую среду.

    Azure Pipelines записывает журнал развертывания. В журнале можно отслеживать изменения в среде обратно в фиксации кода и рабочие элементы.

    A screenshot of Azure Pipelines showing the deployment history. The history shows one successful deployment.

Энди и Мара добавляют этап тестирования в конвейер. Они показывают результаты Амите.

Амита: Мне нравится, что изменения создаются и развертываются, чтобы я смогу протестировать их каждый день. Но я не вижу, как я могу контролировать, когда изменения приходят на промежуточное время.

Мара: Да, развертывание с помощью автоматизации экономит много времени. Помните, что мы включили только запланированный триггер. Давайте добавим утверждение выпуска для вас при настройке промежуточной среды для Тима. Таким образом, изменения переходят к промежуточному режиму только в том случае, если вы будете готовы.