演習 - 開発ステージに昇格する

8 分

チームには計画があり、リリースパイプラインの実装を開始する準備ができています。 Azure DevOps プロジェクトが設定され、Azure App Service インスタンスがビルド成果物を受け取る準備が整いました。

この時点で、チームのパイプラインには 2 つのステージしかないことに注意してください。最初のステージでは、ビルド成果物が生成されます。 2 番目のステージでは、 Space Game Web アプリを App Service にデプロイします。ここでは、Andy と Mara と共にパイプラインを変更します。開発ステージに対応する App Service 環境にデプロイします。

開発ステージは、「Azure Pipelines でのリリースパイプラインの作成」モジュールで行ったデプロイステージに似ています。そこで、CI トリガーを使用してビルドプロセスを開始しました。ここで同じ操作を行います。

GitHub からブランチを取得する

ここでは、GitHub から release ブランチをフェッチします。また、ブランチをチェックアウトするか切り替えます。

このブランチは、 リリース ブランチとして機能します。これには、前のモジュールで使用された Space Game プロジェクトが含まれています。また、最初に使用する Azure Pipelines 構成も含まれています。

ブランチをフェッチして切り替えるには、次の手順を実行します。

Visual Studio Code で、統合ターミナルを開きます。
microsoft リポジトリから release という名前のブランチをフェッチし、そのブランチに切り替えるには、次の git コマンドを実行します。
```
git fetch upstream release
git checkout -B release upstream/release
```
これらのコマンドの形式を使用すると、microsoft GitHub リポジトリ ( upstream と呼ばれます) からスターターコードを取得できます。まもなく、このブランチを GitHub リポジトリ ( origin と呼ばれます) にプッシュします。
省略可能な手順として、Visual Studio Code から azure-pipelines.ymlを開きます。初期構成について理解します。

この構成は、「 Azure Pipelines を使用したリリースパイプラインの作成」モジュールで作成した基本的な構成に似ています。アプリのリリース構成のみがビルドされます。学習目的では、この構成では、前のモジュールで設定した品質チェックやセキュリティチェックは実行されません。

注

より堅牢な構成では、ビルドプロセスに参加するブランチを指定できます。たとえば、コードの品質を検証するために、いずれかのブランチに変更をプッシュするたびに、単体テストを実行できます。さらに包括的なテストを実行する環境にアプリケーションをデプロイすることもできます。ただし、このデプロイは、pull request がある場合、リリース候補がある場合、またはコードを main にマージする場合にのみ実行します。

詳細については、Git と GitHub を使用したビルドパイプラインでのコードワークフローの実装に関するモジュール、およびビルドパイプラインのトリガーに関するページを参照してください。

Dev ステージへの変更をプロモートする

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

Visual Studio Code で、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-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'

この構成は、前のモジュールでビルドした構成に似ています。そこで、あなたとチームは、継続的デプロイの概念実証を構築しました。ただし、上記のコード例で強調表示されているこれらの違いに注意してください。

この構成では、ファイルの先頭に変数が定義されます。変数はパイプライン全体で使用されます。ビルドする構成を定義します (Release)。また、リリースブランチ (release) の名前も定義します。
概念実証からの デプロイ ステージの名前が Dev になりました。
開発ステージでは、前のステージが成功し、現在のブランチがrelease場合にのみ、ステージを実行するようにシステムに指示する条件が使用されます。このセットアップにより、リリース機能が 開発環境 にのみデプロイされるようになります。
デプロイ手順では、 WebAppNameDev 変数を使用して、 開発環境 に関連付けられている App Service インスタンスにデプロイします。

注

実際には、 mainなど、他のブランチからデプロイすることもできます。やreleaseなど、複数のブランチから main ステージに変更を昇格できるようにするロジックを含めることができます。

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

ヒント

これらの Git コマンドを実行する前に、 azure-pipelines.yml保存します。
```
git add azure-pipelines.yml
git commit -m "Deploy to the Dev 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 では、デプロイ履歴が記録されます。履歴では、環境の変更をコードのコミットと作業項目にトレースできます。

演習 - 開発ステージに昇格する

GitHub からブランチを取得する

Dev ステージへの変更をプロモートする

フィードバック