演習 - ステージングにレベル上げする

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

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

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

ここでは、 ステージング用の Azure Pipelines で環境を作成します。 学習目的で、自分を承認者として割り当てます。 実際には、変更が次のステージに進む前に、変更を承認する必要があるユーザーを割り当てます。 Tailspin チームの場合は、変更を "テスト" から "ステージング" にレベル上げできるように Amita が変更を承認します。

このモジュールの前半では、environmentステージとテスト ステージの両方に設定を指定しました。 Dev ステージの例を次に示します。

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

Azure Pipelines を使用して、リリースの特定の条件を含む環境を定義できます。 この条件には、環境へのデプロイが承認されているパイプラインを含めることができます。 また、リリースをあるステージから次のステージに昇格させるために必要な人間の承認を指定することもできます。 ここでは、これらの承認を指定します。

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

1. Azure Pipelines で、[ 環境] を選択します。

   

2. [ 新しい環境] を選択します。

3. 名前 に ステージング と入力します。

4. 残りのフィールドは既定値のままにします。

5. [作成]を選択します。

6. ステージング環境ページで、[承認とチェック] タブを選択します。

7. 承認を選択します。

8. [ 承認者] で、[ ユーザーとグループの追加] を選択し、アカウントを選択します。

9. [ 承認者への指示] で、 ステージングの準備ができたら、「この変更を承認する」と入力します。

10. [作成]を選択します。

変更をステージングにレベル上げする

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

1. 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'
   

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

   ヒント

   デプロイ ステージの 3 つすべてが同様の手順に従うことに気付いたことでしょう。 テンプレートを使用すると、一般的なビルド タスクを 1 回定義し、複数回再利用できます。 この手法は、「 Azure Pipelines を使用したビルド パイプラインの作成 」モジュールで既に使用しています。 学習目的で、各ステージの手順を繰り返します。

2. 統合ターミナルから、インデックス にazure-pipelines.yml を追加します。 次に、変更をコミットして GitHub にプッシュします。

   ヒント

   これらの Git コマンドを実行する前に、 azure-pipelines.yml保存します。

   git add azure-pipelines.yml
   git commit -m "Deploy to Staging"
   git push origin release
   

3. Azure Pipelines で、ビルドに移動します。 実行中のビルドをトレースします。

   ビルドが ステージングに達すると、パイプラインがすべてのチェックに合格するまで待機していることがわかります。 この場合、手動リリース承認という 1 つのチェックがあります。

   

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

   

4. 確認>承認 を選択します。

   実際には、要件を満たしていることを確認するために、変更を検査します。

5. ビルドが完了したら、Web ブラウザーを開きます。 ステージング環境の App Service インスタンスに関連付けられている URL に移動します。

   ブラウザー タブが開いている場合は、ページを更新します。 URL を覚えていない場合は、Azure portal の App Service の詳細 ページで見つけます。

   Space Game Web サイトが App Service にデプロイされ、実行中であることがわかります。

   

6. オプションの手順として、Azure Pipelines で [ 環境] を選択します。 次に、 ステージング 環境を選択します。

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

   

Tailspin チームが集まり、進行状況について話し合います。 Amita は テスト ステージの変更を承認し、他のユーザーは視聴します。

ティム： 実際のところ、最初は自動リリース パイプラインについて少し緊張していました。 しかし、私はそれが動作しているのを見ているので、私は本当にこれが好きです。 各ステージには、独自の環境、関連するテスト、および承認者を含めることができます。 パイプラインは、手動で行う必要があった多くのことを自動化します。 しかし、必要な場所は引き続き制御できます。

Amita:ステージングから運用環境への変更を促進するために、似たようなことを行っているのを想像できます。 運用環境を追加する タイミングについて言 えば、

アンディ： すぐ。 これを追加する前に、まずここでいくつかの部分を入力する必要があると思います。