Azure PipelinesでEnvironmentsの排他デプロイ時挙動の違い

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

Azure DevOps 2021/8/4の更新

Sprint 189が出ないなぁと思っていたらなぜかスキップされてSprint 190がリリースされました。オリジナルはこちらから読んでください。

docs.microsoft.com

Boardsはバグ修正だけのようですが、Pipelinesはいくつか重要な仕様変更や機能追加がありますね。排他的ロックチェックに新しく追加されたsequentialオプションはupstreamとhotfixを別にリリースするような場合、environementに排他チェックをしていると現在は最新のリリースのみ実行されていました。累積的になっている場合はいいのですが、hotfixだけリリースすると累積的になっていないので古いパッチがリリースされず困るケースがあります。そういう時に「順番にすべてのパッチをデプロイしたい」場合に便利ですね。

Ubuntuエージェントの.NET Coreインストールポリシーが変更されましたがWindowsとmacOSも同じポリシーになります。.NET Core SDKの3桁目のマイナーバージョンの先頭桁は機能バージョンとなっており、最新の機能バージョンのみインストールされることになったそうです。9/6からこの仕様変更をうけるので、global.jsonに"rollForward": "patch"が指定されていない場合、9/6以降ビルドが失敗する可能性がありますので気を付けてください。

PublishBuildArtifactsとDownloadBuildArtifactsはすでに非推奨タスクになっていると思いますが、まだ使っている人は早めに移行しましょう。特にself-hostedのエージェントを使っていて、ネットワーク的にエージェントの自動更新ができないような環境ではアーティファクトのダウンロードで失敗することがあります。TLSハンドシェイクのエラーなどでアーティファクトのダウンロードが失敗するような場合はタスクの移行とエージェントの更新を行ってください。

また次6週間後にならないといいですね。ではまた3週間後。

Translate to Japanese to Azure DevOps release not…

Chocolateyからwingetへ移行する

chocolatey.org

今までパッケージ管理にはChocolateyを使っていました。

docs.microsoft.com

Windows 10のwingetが正式版になったということで、移行しよう…と思ったのですが、ChocolateyはWindows Installerのデータベースとは別にパッケージ管理しています。

一台はちょっと力技というか、アンインストール→インストールし直したのですが、どうも無駄。よくよく考えてみればそんな技必要ないようなということで調べたらやっぱりありました。

1. C:\ProgramData\chocolatey\lib配下にある対象パッケージを削除する。依存関係もあるので注意
2. コマンドでパッケージ情報だけを削除する

安全にということで、2番目の公式方法で実行。

choco uninstall パッケージ名 -n --skipautouninstaller

これで綺麗にChocolateyから消えました。とはいっても、Chcolateyを完全に捨てることはできません。wingetはどうもインストーラーがあるツールを前提にしているようで、例えば私が使っているツールではこの辺がサポートされておらず、困っています。

• sysinternals
• hugo
• yarn

他にもツール側が悪いのですが、アプリ内部に更新機能を持っているツールで更新してしまうとWindows Installerのバージョンが更新されないケースがあります。そういう時に明示的にwingetでハッシュを上書きしないといけないのが困りものです。

• Teams
• OBS Studio

など（現時点の情報なので将来変わっているかもしれません）。更新情報のソースとして、Windows Installerのバージョン情報を見ているので、更新を忘れていたツールでもwinget upgradeで一括更新できるのはいいですね。大多数の人にはこれでいいんじゃないかなと思います。

今のところ完全にwingetにするのは開発系のツールでは特に困ることがあるので、Chocolateyと併用しないといけないのは残念ですが、wingetを徐々に使っていく予定です。

（追記）
もう一つ困るケースがありました。例えばSSMSなんですが、言語別にインストーラーが分かれています。WinGetでは一応localeの設定はあるのですが、英語版しか設定されていないためか、自動的に英語版のSSMSがダウンロードされるので、ちょっと困ります。

docs.microsoft.com

SSMSの例。

github.com

これ現在のlocale判定できるようならPR出したほうがいいんでしょうね（割と真剣に困ってる）。

Microsoft MVP Award renewal

ということで、今年も何とかMVP Awardを Developer Technologiesのカテゴリーで受賞できました（11回目です）。ありがとうございます。

ワクチン接種が始まりましたが、まだまだ予断を許さない状態で引きこもり生活は続きそうです。気軽にお話しするということで、足利さんと松村さんの三人で隔週でこんな深夜ラジオやってます。今日もやります。

devblog.connpass.com

最近MicrosoftさんはGitHubを押し出していますが、Azure DevOpsもまだまだ楽しく触っています。GitHubの新しいサービスもいろいろ触らせてもらっています。イベントといえば、ラジオ以外のイベントやってないので、そろそろやりたいなと思っていますが…8月下旬か9月くらい？

また一年間よろしくお願いします。