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

8 分

リリースパイプラインには引き続き 2 つのステージがありますが、以前とは異なるものになっています。ステージは "ビルド" と "開発"です。変更を GitHub にプッシュするたびに、"ビルド" ステージがトリガーされて実行されます。 "開発" ステージは、変更が "リリース" ブランチ内にある場合にのみ実行されます。ここでは、パイプラインに "テスト" ステージを追加します。

チームはスケジュールされたトリガーを使用して、"開発" 段階から毎朝午前 3 時に "テスト" 段階にビルドを昇格することにしたことを思い出してください。スケジュールされたトリガーを設定するには、次のようにします。

ビルド構成にスケジュールを定義します。
"テスト" ステージを定義します。これには、ビルドの理由が Schedule としてマークされている場合にのみステージを実行する条件が含まれています。

学習を目的のため、ここでは、スケジュールを定義しますが、ビルドを "開発" から "テスト" に直接移行できるようにします。この設定により、スケジュールがトリガーされるまで待つ必要がなくなります。このモジュールを完了した後に、スケジュールされた時刻にのみ "テスト" ステージが実行される別の cron 式を試してみてください。

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

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

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'

schedules セクションには、1 つの cron 式が定義されています。ご自分の構成には複数の式を定義できます。この式では、パイプラインが毎日午前 3 時にトリガーされ、リリースブランチに対して実行されます。 always フラグが false に設定されています。これにより、リリースブランチに前回の実行以降の変更が含まれている場合にのみ、パイプラインが実行されます。

Test ステージでは、ビルドの理由が Schedule である場合にのみステージが実行されるように条件が定義されています。 (ビルドの理由は、組み込み変数 Build.Reason で定義されています。)この条件が偽である場合、ステージはスキップされますが、前のステージが引き続き実行されます。

Note

この条件は学習目的のために示されています。これはコメント化されており、スケジュールがトリガーされるのを待つことなく、変更が "開発" から "テスト" に移行されるようになっています。

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

ヒント

これらの Git コマンドを実行する前に、azure-pipelines.yml を保存します。
```
git add azure-pipelines.yml
git commit -m "Deploy to the Test stage"
git push origin release
```
Azure Pipelines でビルドに移動します。実行中に、ビルドをトレースします。
ビルドの完了後、概要ページに戻るには、戻るボタンを選択します。

デプロイが正常に完了したことがわかります。
Web ブラウザーから、ご利用の "テスト" 環境の App Service インスタンスに関連付けられている URL にアクセスします。

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

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

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

Andy と Mara は、パイプラインに "テスト" ステージを追加します。彼らは結果を Amita に示します。

Amita: 私が毎朝テストできるように、変更がビルドされてデプロイされるのがいいですね。でも、変更が "ステージング" に移行されるタイミングを制御する方法がわかりません。

Mara:そうですね。自動化を使用してデプロイすると、時間が大幅に節約されます。スケジュールされたトリガーのみを含めたことを思い出してください。 Tim のために "ステージング" 環境を設定する際に、リリースの承認を追加しましょう。そうすることで、あなたの準備ができた際にのみ変更が "ステージング" に移行されます。

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

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

フィードバック

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

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