练习 - 提升到开发阶段

已完成

该团队有一个计划,并已准备好开始实施其发布流程。 Azure DevOps 项目已设置,Azure 应用服务实例已准备好接收生成项目。

此时,请记住,团队的流程只有两个阶段。 第一个阶段会生成生成工件。 第二阶段将 Space Game Web 应用部署到应用服务。 在此过程中,你将随 Andy 和 Mara 一起调整项目流程。 他们将部署到与 开发 阶段相对应的应用服务环境。

开发阶段类似于你在 Azure Pipelines 模块中创建发布管道中的部署阶段。 在那里,你使用了 CI 触发器来启动生成过程。 在这里也要这样做。

从 GitHub 中提取分支

在这里,你将从 GitHub 提取 release 分支。 你还可以查看或切换到该分支。

此分支会充当你的“发布”分支。 它包含之前模块中使用的 Space Game 项目。 它还包含要从其开始的 Azure Pipelines 配置。

提取并切换到分支:

  1. 在 Visual Studio Code 中打开集成终端。

  2. 若要从Microsoft存储库中提取名为 release 的分支,并切换到该分支, git 请运行以下命令。

    git fetch upstream release
    git checkout -B release upstream/release
    

    这些命令的格式使你可以从 Microsoft GitHub 存储库(称为) upstream获取入门代码。 不久,你将将此分支推送到 GitHub 存储库,称为 origin

  3. 作为可选步骤,从 Visual Studio Code 打开 azure-pipelines.yml。 熟悉初始配置。

    该配置类似于使用 Azure Pipelines 模块在创建发布管道 中创建的基本配置。 它仅生成应用的发布配置。 出于学习目的,此配置不会运行在上一模块中设置的质量或安全检查。

    注释

    可以使用更可靠的配置来指定参与生成过程的分支。 例如,为了帮助验证代码质量,你可以在每次对任何分支推送更改时运行单元测试。 你还可以将应用程序部署到执行更全面测试的环境。 但仅当你有拉取请求、候选发布或将代码合并到主分支时,才能执行此部署。

    有关详细信息,请参阅使用 Git 和 GitHub 在生成管道中实现代码工作流生成管道触发器

将更改提升到“开发”阶段

在这里,修改管道配置,将构建提升到 开发 阶段。

  1. 在 Visual Studio Code 中,修改 azure-pipelines.yml

    trigger:
    - '*'
    
    variables:
      buildConfiguration: 'Release'
      releaseBranchName: 'release'
    
    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'
    

    此配置类似于在上一模块中生成的配置。 在那里,你和团队为持续部署构建了概念证明。 但请注意上述代码示例中突出显示的这些差异:

    • 此配置定义文件开头的变量。 这些变量用于整个管道。 它们定义要生成的配置(Release)。 它们还定义了发布分支的名称(release)。
    • 概念证明中的 部署 阶段现已命名 为 Dev
    • 开发阶段使用一个条件,该条件指示系统仅在上一阶段成功且当前分支release为时运行该阶段。 此设置可确保仅将发布功能部署到 开发 环境。
    • 部署步骤使用 WebAppNameDev 变量部署到与 开发 环境关联的应用服务实例。

    注释

    在实践中,可以从其他分支(例如 main)进行部署。 可以包括允许从多个分支(例如release)将更改提升到main阶段的逻辑。

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

    小窍门

    运行这些 Git 命令之前,请保存 azure-pipelines.yml

    git add azure-pipelines.yml
    git commit -m "Deploy to the Dev stage"
    git push origin release
    
  3. 在 Azure Pipelines 中,转到生成。 在生成运行时对其进行跟踪。

  4. 生成完成后,若要返回到摘要页,请选择“后退”按钮。

    Azure Pipelines 的屏幕截图,显示已完成的阶段。

    你会看到部署成功完成。

  5. 在 Web 浏览器中,转到与 开发 环境的应用服务实例关联的 URL。

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

    你会看到 Space Game 网站已部署到应用服务,并且正在运行。

    Web 浏览器的屏幕截图,其中显示了开发环境中的 Space Game 网站。

  6. 作为可选步骤,在 Azure Pipelines 中选择“ 环境”。 然后选择 开发 环境。

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

    Azure Pipelines 的屏幕截图,其中显示了部署历史记录。历史记录显示一个成功的部署。