练习 - 提升到过渡

8 分钟

发布管道现在有三个阶段：“生成”、“开发”和“测试”。你和 Tailspin 团队还要实现一个阶段：“过渡”。

在本部分中，你将：

在 Azure Pipelines 中创建“过渡”环境，并将自己分配为审批者。
定义“过渡”阶段，此阶段仅在审批者验证“测试”阶段的结果后才运行。

创建过渡环境

在这里，你将在 Azure Pipelines 中创建用于“过渡”的环境。为便于学习，你将自己分配为审批者。在实践中，你将分配用户，在将更改移动到下一个阶段之前，他们需要批准这些更改。对于 Tailspin 团队，Amita 批准更改，这样它们就可以从“测试”提升到“过渡”。

在本模块前面的部分中，你为“开发”和“测试”阶段指定了 environment 设置。下面是“开发”阶段的示例。

- stage: 'Deploy'
  displayName: 'Deploy the web application'
  dependsOn: Build
  jobs:
  - deployment: Deploy
    pool:
      vmImage: 'ubuntu-20.04'
    environment: dev
    variables:
    - group: Release

可以通过 Azure Pipelines 定义一个环境，其中包含发布的特定条件。此条件可以包括授权部署到环境中的管道。你还可以指定将发布从一个阶段提升到下一个阶段所需的人工审批。在此处指定这些审批。

创建“过渡”环境：

在 Azure Pipelines 中，选择“Environments”。
选择“新建环境”。
在“名称”下输入“过渡”。
让其余字段保留其默认值。
选择“创建”。
在“过渡”环境页面上，打开下拉列表，然后选择“审批和检查”。
选择“审批”。
在“审批者”下，选择“添加用户和组”，然后选择你的帐户。
在“审批者说明”下，输入“在准备好进行过渡时批准此更改”。
选择“创建”。

将更改提升到过渡

在这里，你将修改管道配置，以将生成部署到“过渡”阶段。

在 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'

- stage: 'Staging'
  displayName: 'Deploy to the staging environment'
  dependsOn: Test
  jobs:
  - deployment: Deploy
    pool:
      vmImage: 'ubuntu-20.04'
    environment: staging
    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: '$(WebAppNameStaging)'
              package: '$(Pipeline.Workspace)/drop/$(buildConfiguration)/*.zip'

此代码添加“过渡”阶段。该阶段部署到“过渡”环境，其中包括发布审批。

提示

你可能已注意到，所有三个部署阶段都遵循类似的步骤。你可以使用模板一次性定义公共生成任务并多次重复使用它们。你已在使用 Azure Pipelines 创建生成管道模块中使用了此方法。为便于学习，我们在每个阶段中重复执行这些步骤。

在集成终端中，将 azure-pipelines.yml 添加到索引中。接下来，提交更改，并将其推送到 GitHub。

提示

在运行这些 Git 命令之前，请保存 azure-pipelines.yml。
```
git add azure-pipelines.yml
git commit -m "Deploy to Staging"
git push origin release
```
在 Azure Pipelines 中，转到生成。在生成运行时对其进行跟踪。

当生成到达“过渡”时，会看到管道等待所有检查通过。在本例中，只有一个检查，即手动发布审批。

你可以将 Azure DevOps 配置为在生成需要审批时向你发送电子邮件通知。下面是一个示例：
选择“审阅”>“批准”。

实际上，若要验证它们是否满足你的要求，需要检查更改。
生成完成后，打开 Web 浏览器。转到与过渡环境的应用服务实例关联的 URL。

如果浏览器选项卡仍处于打开状态，请刷新页面。如果你忘记了 URL，可在 Azure 门户中的应用“服务详细信息”页上找到它。

你会看到 Space Game 网站部署到应用服务，并且正在运行。
（可选）在 Azure Pipelines 中选择“环境”。接下来，选择“过渡”环境。

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

Tailspin 团队聚集在一起讨论他们的进展。 Amita 批准“测试”阶段中的更改，而其他人则进行监视。

Tim：说实话，起初我对自动发布管道有些不安。但我现在真的很喜欢它，因为我看到它起作用了。每个阶段都可以有自己的环境、关联的测试和审批者。管道将许多我们必须手动执行的操作自动化。但是我们仍然可以在需要的地方进行控制。

Amita：我可以想象我们执行类似的操作，将更改从“过渡”提升到“生产”。说到这个...我们何时添加生产环境？

Andy：很快了。我认为在添加生产环境之前，我们仍然需要先在此处填写几项信息。

继续

练习 - 提升到过渡

创建过渡环境

将更改提升到过渡

反馈