下一步

练习 - 提升到测试阶段

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 门户中的应用“服务详细信息”页上找到它。

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

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

Andy 和 Mara 将“测试”阶段添加到管道。他们将结果展示给 Amita。

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

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

继续

练习 - 提升到测试阶段

将更改提升到开发阶段

反馈