演習 - ステージングに昇格させる

8 分

リリースパイプラインは、"ビルド"、"開発"、"テスト" の 3 つのステージになりました。あなたと Tailspin チームは、もう 1 つのステージ ("ステージング") を実装します。

このパートでは、次のことを行います。

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] を選択します。
[New environment] (新しい環境) を選択します。
[Name] に "ステージング" と入力します。
残りのフィールドは既定値のままにします。
［作成］ を選択します
ステージング環境のページで、ドロップダウンを開いて、[Approvals and checks] を選択します。
[Approvals] を選択します。
[Approvers] で [Add users and groups] を選択し、アカウントを選択します。
[Instructions to approvers] に "ステージングの準備ができたら、この変更を承認する" と入力します。
[作成] を選択します。

変更をステージングに昇格させる

ここでは、パイプライン構成を変更して、ビルドを "ステージング" ステージにデプロイします。

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'

このコードには、Staging ステージが追加されています。このステージは、リリースの承認を含むステージング環境にデプロイされます。

ヒント

3 つのデプロイステージはすべて同様の手順に従っていることに気づかれたと思います。 "テンプレート" を使用すると、共通のビルドタスクを 1 回定義して、それを複数回再利用できます。この手法は、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 でビルドに移動します。実行中に、ビルドをトレースします。

ビルドが "ステージング" に移行されると、すべてのチェックが成功するまでパイプラインが待機状態になることがわかります。この場合は、1 つのチェック (手動でのリリースの承認) があります。

ビルドの承認が必要な場合に電子メール通知を送信するように Azure DevOps を構成できます。次に例を示します。
[Review]>[Approve] を選択します。

実際には、要件が満たされていることを確認するために、変更を検査します。
ビルドが完了したら、Web ブラウザーを開きます。 ステージング環境の App Service インスタンスに関連付けられている URL に移動してください。

ブラウザーのタブを開いたままにしていた場合は、ページを更新します。 URL を覚えていない場合は、Azure portal の [App Service details] ページで見つけます。

Space Game Web サイトが App Service にデプロイされ、実行されていることがわかります。
省略可能な手順として、Azure Pipelines で [Environments] を選択します。次に、ステージング環境を選択します。

Azure Pipelines では、デプロイの履歴が記録されます。これにより、環境の変更をコードのコミットと作業項目までトレースできます。

Tailspin チームが、進行状況について話し合うために集まっています。 Amita が、他のメンバーが見ている前で、"テスト" ステージの変更を承認します。

Tim: 正直に言うと、最初は自動化されたリリースパイプラインについて少し不安に思っていました。でも、動作しているところを見て安心しました。各ステージでは、独自の環境、関連付けられたテスト、承認者を持つことができます。パイプラインでは、手動で行う必要がある多くの処理が自動化されます。それでも必要なところは引き続き制御できます。

Amita: 変更を "ステージング" から "運用環境" に昇格させる場合と似たような手順を行うことを想像できます。そういえば、いつ運用環境を追加しますか?

Andy:もうすぐです。加える前に、まずここにいくつかのピースを加える必要がまだあると思います。

演習 - ステージングに昇格させる

ステージング環境を作成する

変更をステージングに昇格させる

フィードバック