练习 - 提升到测试阶段

8 分钟

你的发布管道仍有两个阶段，但它们现在与之前不同。阶段为 “生成 ”和 “开发”。推送到 GitHub 的每个更改都会触发要运行的生成阶段。仅当更改位于发布分支中时，开发阶段才会运行。在这里，将测试阶段添加到管道。

回想一下，团队决定每天凌晨3点使用计划触发器将构建从开发阶段提升到测试阶段。设置计划的触发器：

在生成配置中定义计划。
定义测试阶段，其中包括仅在生成原因被标记为 Schedule时运行阶段的条件。

基于学习目的，在此指定计划，并允许构建直接从开发到测试。此设置无需等待计划被触发。完成本模块后，请尝试使用不同的 cron 表达式进行试验，以便仅在计划的时间运行测试阶段。

将更改提升到开发阶段

在这里，您需要修改管道配置，将构建部署到测试阶段。

在 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，则跳过该阶段，但前面的阶段将继续运行。

注释

出于学习目的，将显示此条件。建议启用将更改从“开发”提升到“测试”而无需等待触发计划。

在集成终端中，将 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
```
在 Azure Pipelines 中，转到生成。在生成运行时对其进行跟踪。
生成完成后，若要返回到摘要页，请选择“后退”按钮。

你会看到部署成功完成。
在 Web 浏览器中，转到与测试环境的应用服务实例关联的 URL。

如果仍打开浏览器选项卡，请刷新页面。如果不记得 URL，可在 Azure 门户中的 “应用服务详细信息 ”页上找到该 URL。

你会看到 Space Game 网站已部署到应用服务，并且它正在运行。
作为可选步骤，在 Azure Pipelines 中选择“ 环境”。然后选择测试环境。

Azure Pipelines 记录部署历史记录。在历史记录中，可以将环境中的更改跟踪回代码提交和工作项。

Andy 和 Mara 将测试阶段添加到管道。他们向阿米塔展示了结果。

Amita： 我喜欢生成和部署这些更改，以便我可以每天早上测试这些更改。但我不知道如何在更改到达“过渡”时对其进行控制。

玛拉： 是的，通过自动化进行部署可以节省大量时间。请记住，我们仅包含计划的触发器。在为 Tim 设置“过渡”环境时，让我们为你添加发布审批。这样一来，只有在你准备就绪后，更改才会移到“过渡”环境。

练习 - 提升到测试阶段

将更改提升到开发阶段

反馈