Задание - Перевести на этап тестирования

Завершено

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

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

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

В учебных целях вы определяете расписание, но позволяете сборке переходить непосредственно из Dev на Test. Эта настройка позволяет избежать необходимости ждать активации расписания. После завершения этого модуля попробуйте поэкспериментировать с различными выражениями 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 определяет причину сборки.) Если это условие ложное, стадия пропускается, но предыдущие стадии продолжают выполняться.

    Заметка

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

  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. После завершения сборки, чтобы вернуться на страницу сводки, нажмите кнопку "Назад".

    Снимок экрана Azure Pipelines с тремя завершенными этапами: сборка, разработка и тестирование.

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

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

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

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

    Снимок экрана веб-браузера с веб-сайтом Space Game в тестовой среде.

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

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

    Снимок экрана Azure Pipelines с журналом развертывания. В журнале показано одно успешное развертывание.

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

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

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