在Azure DevOps创建multistage pipeline

最新推荐文章于 2023-04-15 21:56:33 发布

jack@london

最新推荐文章于 2023-04-15 21:56:33 发布

阅读量1.3k

点赞数

分类专栏： Azure 文章标签： azure devops

本文链接：https://blog.csdn.net/figosoar/article/details/109219703

版权

Azure 专栏收录该内容

69 篇文章 1 订阅

订阅专栏

前提：

Azure DevOps创建Project

本地下载从GitHub folk的代码，配置好远端分支。

（使用Cloudshell）创建Azure App Service环境。参见：https://docs.microsoft.com/zh-cn/learn/modules/create-multi-stage-pipeline/3-set-up-environment

在Azure Pipelines创建pipeline variables

创建service connection。

At this point, remember that the team's pipeline has only two stages. The first stage produces the build artifact. The second stage deploys the Space Game web application to App Service. Here you follow along with Andy and Mara as they modify the pipeline. They'll deploy to the App Service environment that corresponds to the Dev stage.

The Dev stage resembles the deployment stage that you made in the Create a release pipeline in Azure Pipelines module. There, you used a CI trigger to start the build process. Here you do the same.

Promote changes to the Dev stage

参见：https://docs.microsoft.com/zh-cn/learn/modules/create-multi-stage-pipeline/4-promote-dev

Here you modify your pipeline configuration to promote the build to the Dev stage.

In Visual Studio Code, modify 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-18.04'
      demands:
      - npm

    variables:
      wwwrootDir: 'Tailspin.SpaceGame.Web/wwwroot'
      dotnetSdkVersion: '3.1.300'

    steps:
    - task: UseDotNet@2
      displayName: 'Use .NET Core 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-18.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'

This configuration resembles the one that you built in the previous module. There, you and the team built a proof of concept (POC) for continuous deployment. But note these differences, which are highlighted in the preceding code example:

This configuration defines variables at the top of the file. The variables are used throughout the pipeline. They define which configuration to build (Release). They also define the name of your release branch (release).
The Deploy stage from the POC is now named Dev.
The Dev stage uses a condition that directs the system to run the stage only when the previous stage succeeds and the current branch is release. This setup ensures that release features are deployed only to the Dev environment.
The deployment step uses the WebAppNameDev variable to deploy to the App Service instance that's associated with the Dev environment.

In practice, you might deploy from some other branch, such as master. You can include logic that allows changes to be promoted to the Dev stage from multiple branches, such as release and master.

From the integrated terminal, add azure-pipelines.yml to the index. Commit the change and push it up to GitHub.

Save azure-pipelines.yml before you run these Git commands.
```
git add azure-pipelines.yml
git commit -m "Deploy to the Dev stage"
git push origin release
```
In Azure Pipelines, go to the build. Trace the build as it runs.
After the build finishes, select the back button to return to the summary page.

You see that the deployment finished successfully.
From a web browser, navigate to the URL that's associated with the App Service instance for your Dev environment.
As an optional step, in Azure Pipelines, select Environments. Then select the dev environment. Azure Pipelines records your deployment history. In the history, you can trace the environment's changes back to code commits and work items.

Promote to the Test stage

参见：https://docs.microsoft.com/zh-cn/learn/modules/create-multi-stage-pipeline/5-promote-test

Your release pipeline still has two stages, but they're now different than before. The stages are Build and Dev. Every change you push to GitHub triggers the Build stage to run. The Dev stage runs only when the change is in the release branch. Here you add the Test stage to the pipeline.

Recall that the team decided to use a scheduled trigger to promote the build from the Dev stage to the Test stage at 3 A.M. each morning. To set up the scheduled trigger:

Define the schedule in your build configuration.
Define the Test stage, which includes a condition that runs the stage only if the build reason is marked as Schedule.

For learning purposes, here you define the schedule but allow the build to go directly from Dev to Test. This setup avoids the need to wait for the schedule to be triggered. After you complete this module, experiment with different cron expressions to run the Test stage only at the scheduled time.

Promote changes to the Test stage

Here you modify your pipeline configuration to deploy the build to the Test stage.

In Visual Studio Code, modify azure-pipelines.yml like this:

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-18.04'
      demands:
      - npm

    variables:
      wwwrootDir: 'Tailspin.SpaceGame.Web/wwwroot'
      dotnetSdkVersion: '3.1.300'

    steps:
    - task: UseDotNet@2
      displayName: 'Use .NET Core 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-18.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-18.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'

The schedules section defines one cron expression. You can define more than one expression in your configuration. The expression triggers the pipeline to run against the release branch at 3 A.M. each day. The always flag is set to false so that the pipeline runs only when the release branch contains changes from the prior run.

The Test stage defines a condition that runs the stage only when the build reason equals Schedule. (The built-in variable Build.Reason defines the build reason.) If this condition is false, the stage is skipped, but the prior stages continue to run.

This condition is shown for learning purposes. It's commented to enable the change to go from Dev to Test without waiting for the schedule to be triggered.

From the integrated terminal, add azure-pipelines.yml to the index. Then commit the change and push it up to GitHub.

Save azure-pipelines.yml before you run these Git commands.
```
git add azure-pipelines.yml
git commit -m "Deploy to the Test stage"
git push origin release
```
In Azure Pipelines, go to the build. Trace the build as it runs.
After the build finishes, select the back button to return to the summary page.

You see that the deployment finished successfully.
From a web browser, navigate to the URL that's associated with the App Service instance for your Test environment.

Promote to Staging

参见：https://docs.microsoft.com/zh-cn/learn/modules/create-multi-stage-pipeline/6-promote-staging

Your release pipeline now has three stages: Build, Dev, and Test. You and the Tailspin team have one more stage to implement: Staging.

In this part, you'll:

Create the staging environment in Azure Pipelines and assign yourself as an approver.
Define the Staging stage, which runs only after an approver verifies the results of the Test stage.

Create the staging environment

Here you create an environment in Azure Pipelines for Staging. For learning purposes, you assign yourself as the approver. In practice, you would assign the users who are required to sign off on changes before those changes move to the next stage. For the Tailspin team, Amita approves changes so that they can be promoted from Test to Staging.

In this example, Azure Pipelines creates your dev environment if it doesn't exist. You can also define an environment through Azure Pipelines that includes specific criteria for your release. This criteria can include the pipelines that are authorized to deploy to the environment. You can also specify the human approvals that are needed to promote the release from one stage to the next. Here you specify those approvals.

To create the staging environment:

From Azure Pipelines, select Environments.
Select New environment.
Under Name, enter staging.
Leave the remaining fields at their default values.
Select Create.
On the staging environment page, open the drop-down menu, and then select Approvals and checks.
Select Approvals.
Under Approvers, select Add users and groups and then select your account.
Under Instructions to approvers, enter Approve this change when it's ready for staging.
Select Create.

Promote changes to Staging

Here you modify your pipeline configuration to deploy the build to the Staging stage.

In Visual Studio Code, modify azure-pipelines.yml like this:

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-18.04'
      demands:
      - npm

    variables:
      wwwrootDir: 'Tailspin.SpaceGame.Web/wwwroot'
      dotnetSdkVersion: '3.1.300'

    steps:
    - task: UseDotNet@2
      displayName: 'Use .NET Core 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-18.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-18.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-18.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'

This code adds the Staging stage. The stage deploys to the staging environment, which includes a release approval.

You probably noticed that all three of your deployment stages follow similar steps. You can use templates to define common build tasks one time and reuse them multiple times. You already used this technique in the Create a build pipeline with Azure Pipelines module. For learning purposes, we repeat the steps in each stage.

From the integrated terminal, add azure-pipelines.yml to the index. Then commit the change and push it up to GitHub.

Save azure-pipelines.yml before you run these Git commands.
```
git add azure-pipelines.yml
git commit -m "Deploy to Staging"
git push origin release
```
In Azure Pipelines, go to the build. Trace the build as it runs.

When the build reaches Staging, you see that the pipeline waits for all checks to pass. In this case, there's one check: the manual release approval.

You can configure Azure DevOps to send you an email notification when the build requires approval. Here's an example:
Select Review > Approve.

In practice, you would inspect the changes to verify that they meet your requirements.
After the build finishes, open a web browser. Navigate to the URL that's associated with the App Service instance for your staging environment.