Azure PipelinesでEnvironmentsを使った場合、様々なチェックがかけられます。
- 承認
- デプロイ時間制限
- コンテナーイメージ入手元チェック
- Azure Policy評価
- Gitブランチチェック
- Azure Functionを実行
- REST API呼び出し
- Azure Monitorでの呼び出し先評価
- パイプラインのテンプレートに所定のものを使っているか
- 排他制御
この中で最後の排他制御というのは複数の人間が同時にコミットした場合でも、順番に一つずつデプロイを実施するという機能です。ドキュメントではすごく簡単に書かれていますが、わかりづらいですよね。
docs.microsoft.com
今までの挙動としては、「一番最後にデプロイしたもののみがデプロイされる」という挙動になっています。
master/mainやreleaseブランチのように修正が必ず累積的になっている場合はこれでいいのですが、緊急修正のパッチのように、特定の箇所だけ修正してリリースすることになると、必ずしも修正が累積的になっていない場合があります。それで最後のhotfixのリリースだけデプロイされると途中のhotfixが本番に入らないことになって問題になります。
この問題を解決するのがSprint 190の新機能lockBehaviorです。
docs.microsoft.com
イメージではこうなります。下のlockBehavior: runLatestが今までの挙動で、同じEnvironmentにデプロイする場合「最新の」ものだけデプロイされます。図ではhotfix/2ブランチのコミットがデプロイされないという挙動です。
Sprint 190の新機能lockBehavior: sequentialをYAMLで指定すると、Environmentへのデプロイすべてが順番に行われることになります。
Environmentを作成して、Exclusive Lockを指定します。次にYAMLにlockBehavior: sequentialを指定します。stageでもpipeline全体どちらでもいいのですが、実験した範囲ではpipeline全体に指定しないと動かなかったような…もうちょっと調べてみます。
lockBehavior: sequentialを指定した場合、hotfix/1348,hotfix/1349,hotfix/1350それぞれのブランチがデプロイされました。
今度は逆にlockBehavior: runLatestもしくは、指定しない場合、最初と最後のデプロイだけ実行されます。
真ん中のhotfix/1349ブランチのデプロイが行われていません。
詳細を見ても、キャンセルされたと表示されています。大きなデプロイでこの挙動を使うと安全にhotfixのデプロイができるようになるのでぜひ使ってみてください。
(追加)
GitHubに使ったYAMLを含めたサンプルを用意しました
github.com
