今年の5月に、Azure DevOps の Build と Release のパイプラインに代わって、Multi-Stage Pipelines で構築できるようになる発表がありました。
devblogs.microsoft.com
現時点では、Multi-Stage Pipelines はプレビュー機能ですが、従来の Build と Release のパイプラインは Classic 扱いとなっているので、そろそろ触っておかねばと思い、試してみました。
前準備
Azure DevOps の右上のユーザーアイコンから、Preview features で Multi-Stage Pipelines を有効にします。
あとは、デプロイ先の Azure Web Apps のサブスクリプション情報を service connection として登録しておきます。
パイプラインの全体設計
今回は、リポジトリのブランチとデプロイ先の関係が分かりやすい GitLab flow を想定しています。
パイプラインは、自動デプロイされる開発環境向け（Commit Stage）と承認デプロイされる本番環境向け（Production Stage）を作ります。
YAML を Build と Release を分けて、可変部をパラメータで切り替えできるテンプレートを作ることで再利用性を向上させます。
開発環境向けパイプライン
まずは、パイプライン起動用の azure-pipelines.yml です。
trigger:
- master
variables:
imageName: 'windows-2019'
buildConfiguration: 'Release'
projects: '**/WebApplication.csproj'
testProjects: '**/WebApplication.Tests.csproj'
azureSubscription: 'AzureSponsorships'
webAppsName: '<Web Apps Name>'
webAppsType: 'webApp'
environment: 'Commit-Stage'
stages:
- stage: Build
jobs:
- template: pipelines/build-pipelines.yml
parameters:
imageName: $(imageName)
buildConfiguration: $(buildConfiguration)
projects: $(projects)
testProjects: $(testProjects)
- stage: Release
dependsOn:
- Build
condition: and(succeeded(), eq(variables['Build.SourceBranch'], 'refs/heads/master'))
jobs:
- template: pipelines/release-pipelines.yml
parameters:
imageName: $(imageName)
azureSubscription: $(azureSubscription)
webAppsName: $(webAppsName)
webAppsType: $(webAppsType)
environment: $(environment)
ポイントは、template で Build と Release のYAMLを指定している箇所です。condition で、Build ステージが成功した場合のみ、Release ステージを実行する条件指定も忘れずに設定します。
リリースの JOB は、Environments を使います。
開発環境向けパイプラインでは、自動デプロイしたいので、空の Environments を Commit-Stage で登録しておきます。
次に、ビルド用の build-pipelines.yml です。
parameters:
imageName: ''
buildConfiguration: ''
projects: ''
testProjects: ''
jobs:
- job: Build
pool:
vmImage: ${{parameters.imageName}}
steps:
- task: DotNetCoreCLI@2
displayName: 'Build'
inputs:
command: 'build'
projects: ${{parameters.projects}}
arguments: '--configuration ${{parameters.buildConfiguration}}'
- task: DotNetCoreCLI@2
displayName: 'Test'
inputs:
command: 'test'
projects: ${{parameters.testProjects}}
arguments: '--configuration ${{parameters.buildConfiguration}}'
- task: DotNetCoreCLI@2
displayName: 'Publish'
inputs:
command: 'publish'
publishWebProjects: true
arguments: '--configuration ${{parameters.buildConfiguration}} --output $(System.DefaultWorkingDirectory)/publish'
zipAfterPublish: true
- publish: publish
displayName: 'Publish artifact'
artifact: webapp
.NET Core CLI task の DotNetCoreCLI@2 を使って、ビルド→テスト→発行を行っています。
最後に、リリース用の release-pipelines.yml です。
parameters:
imageName: ''
azureSubscription: ''
webAppsName: ''
webAppsType: ''
webAppsSlotName: 'production'
environment: ''
logLevel: 'Information'
jobs:
- deployment: Deploy_WebApps
displayName: 'Release'
pool:
vmImage: ${{parameters.imageName}}
environment: ${{parameters.environment}}
strategy:
runOnce:
deploy:
steps:
- task: AzureWebApp@1
displayName: 'Deploy to Azure Web Apps'
inputs:
azureSubscription: ${{parameters.azureSubscription}}
appType: ${{parameters.webAppsType}}
appName: ${{parameters.webAppsName}}
slotName: ${{parameters.webAppsSlotName}}
package: '$(Pipeline.Workspace)/**/*.zip'
deploymentMethod: runFromPackage
appSettings: -Logging:LogLevel:Default ${{parameters.logLevel}}
Azure Web App task の AzureWebApp@1 を使って、デプロイを行っています。
Azure Web Apps の Deployment Slot 機能にも対応したいので、slotName を指定しますが、必須にはしたくないので、初期値で production を設定しています。
appSettings では、アプリケーション設定のログレベルを設定しています。Azure CLI の az webapp config コマンドでも設定できますが、リソースグループ名が必要になってしまうので、ここで指定しました。
本番環境向けパイプライン
パイプライン起動用の azure-pipelines-production.yml です。
trigger:
- production
variables:
imageName: 'windows-2019'
buildConfiguration: 'Release'
projects: '**/WebApplication.csproj'
testProjects: '**/WebApplication.Tests.csproj'
azureSubscription: 'AzureSponsorships'
webAppsName: '<Web Apps Name>'
webAppsType: 'webApp'
environment: 'Production-Stage'
webAppsSlotName: 'staging'
stages:
- stage: Build
jobs:
- template: pipelines/build-pipelines.yml
parameters:
imageName: $(imageName)
buildConfiguration: $(buildConfiguration)
projects: $(projects)
testProjects: $(testProjects)
- stage: Release
dependsOn:
- Build
condition: and(succeeded(), eq(variables['Build.SourceBranch'], 'refs/heads/production'))
jobs:
- template: pipelines/release-pipelines.yml
parameters:
imageName: $(imageName)
azureSubscription: $(azureSubscription)
webAppsName: $(webAppsName)
webAppsType: $(webAppsType)
environment: $(environment)
webAppsSlotName: $(webAppsSlotName)
トリガーとなるブランチが production となっている箇所が開発環境向けパイプラインとの違いです。
本番環境では、Azure Web Apps の Deployment Slot 機能を利用したいので、staging を設定しています。また、承認デプロイもしたいので、承認設定した Environments を Production-Stage で登録しておきます。
結果確認
リポジトリの master ブランチへの更新がトリガーとなり、ビルドとリリースのパイプラインが実行され、Azure Web Apps へのデプロイまでが自動で実行されます。
master ブランチから production ブランチへプルリクエストのマージがトリガーとなり、ビルドとリリースのパイプラインが実行されます。Azure Web Apps へのデプロイは承認が必須となっているので、Waiting になっていることが分かります。
この後、リリースを承認すると、Deployment Slot の staging へデプロイされます。最終動作確認後、Azure Portal などからの Swap することを想定しています。万が一、リリースによる障害が発生した場合には、旧バージョンに切り戻すこともできます。
まとめ
Azure DevOps の Multi-Stage Pipelines を使って、Azure Web Apps 向けのパイプラインを構築してみました。
可変部をパラメータで切り替えできるようにテンプレート化しているので、これからの CI/CD が捗りそうです。
こちらから、パイプライン YAML の全体を確認できます。
github.com
追記
今回のユースケースですと、YAML をソースコードのリポジトリで管理する想定なので、環境毎に異なる情報やパスワードなどのシークレットな情報をリポジトリに含めたくありません。
Azure DevOps の Variable groups を使って、パイプラインを書き換えてみましたので、こちらを参照してください。
gooner.hateblo.jp
