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

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 によってビルド理由が定義されます)。この条件が false の場合、ステージはスキップされますが、前のステージは引き続き実行されます。

注

この条件は学習目的で表示されます。スケジュールがトリガーされるのを待たずに、Dev から Test への変更を有効にするためのコメントが付けられています。

統合ターミナルからインデックスに、 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 の詳細 ページで見つけます。

Space Game Web サイトが App Service にデプロイされ、実行中であることがわかります。
オプションの手順として、Azure Pipelines で [ 環境] を選択します。次に、 テスト 環境を選択します。

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

Andy と Mara は 、パイプラインにテスト ステージを追加します。結果が Amita に表示されます。

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

マラ： はい。自動化によってデプロイすると、時間が大幅に節約されます。スケジュールされたトリガーのみが含まれていることに注意してください。 Tim の ステージング 環境を設定するときに、リリース承認を追加しましょう。そうすることで、準備ができたときにのみ変更が ステージング に移行します。

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

変更をテストステージにプロモートする

フィードバック

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