kkamegawa's weblog

Visual Studio,TFS,ALM,VSTS,DevOps関係のことについていろいろと書いていきます。Google Analyticsで解析を行っています

Azure DevOps 2020/6/18の更新

Azure DevOps Sprint 171のリリースノートの翻訳を行いました。オリジナルはこちらから読んでください。

docs.microsoft.com

Linux/ARM64のビルドエージェントが登場しました。コンパイルはそうでもなかったけど、それ以外(何?)にいろいろ手間取ったためだそうで。現実問題どのマシンで動かせばいいんだろうかという気もします。ラズパイ?もしかして、AzureにARMベースのLinuxのVM提供とか今後計画あるんだろうか。

今までチームかプロジェクトの管理者(Administrator)持っていたらユーザーの招待ができたのですが、これをProject Collection Administrator(organization所有者がデフォルトで入っています)の人のみに制限できるようになります。誰彼と招待されると困るというような場合に使えます。

オンプレミスAzure DevOps ServerではXMLで一から作り上げるプロセステンプレートという仕組みがあったのですが、今はGUIで簡単にできる継承モデルに変わっています。オンプレミスでは今のところ移行する方法はありませんが、計画にはあるようです。XMLと継承モデルには機能差がかなりあるのですが、それを埋めるための差分の一つ、「Work ItemのStateをNewからDoneへ一気に変更できなくする」という機能の提供をプライベートプレビューで始めるようです。興味のある方は担当者のメールアドレスがリンクされているので、英語でどうぞ。簡単なやつでいいです。

パイプラインでタグによるフィルタリングのサポート、特定のタスクをビルドでは無効にするけど、リリースでは使用可能にするという設定を作者ができるようになるそうです。いいですね。詳しくはtfxのドキュメントをどうぞ、だそうです。

ではまた三週間後。

Translate to Japanese to Azure DevOps release not…

REST APIでTest Itemを作る方法とサンプル

Excelでテストケースを管理したい、だからテストケース管理ツールの類はやだなぁ、という話は割とどこでもあると思います。ただ、莫大なExcelで結果に署名するだけの簡単なお仕事といっても、「ねぇ母さんあの時やったテスト結果のExcelファイルはどこに行ったんでしょう」ということで探すのも大変です。

マネージメント層はExcelでその時だけ結果が見れば大体満足、しかし品質として管理するなら、ちゃんと履歴として残したい、要件と関連付けて管理するほうがいいのですが、なかなかやらない。Azure DevOpsの拡張機能の中にはテストをオフラインでやれるようにExportするものもありますが、逆はない。

marketplace.visualstudio.com

そんなわけで、こんなツールを作ってみました。

github.com

"Sync"とついていますが、一方通行です、すいません。Azure Functionsにデプロイすると動いてない(3.1にしたらこのありさま…)とかありますが、ちょっと調べます。仕組みとしては、SharePointに所定の形式のExcelファイルをアップロードすると、AutomateでAzure Functionsを呼び出して、REST APIでAzure DevOpsに登録します。テストケースを書くのは慣れたExcelで、テスト結果はAzure DevOpsで管理できてハッピーです(たぶん)。

一番悩んだのがTest Stepを登録するところでした。

テスト手順と期待値を登録するとき、html形式で登録することはわかっていたんですが、どうやるのかといえばJSONでこんな形式で登録するということでした。このあたり

{
  "Value" = "steps", 
  "Operation" = "add", 
  "Path" = "/fields/Microsoft.VSTS.TCM.Steps"
}

learn.microsoft.com

Work Itemの作成は普通にわかりやすいREST APIなのですが、Pathの記述方法がわからなかった。試行錯誤して調べたら、同じくREST APIのWork Item Types Fieldに一覧があって、Pathの指定にはこの値を書けばいいということがわかって一気に進みました。Work Item上にあるフィールドは全部このFieldで定義されているPath形式で指定することになります。

あと、Work Itemを作るAPIは複数のFieldを一度に登録するほうがうまく動くようで、Title(/fields/System.Title)と一緒に指定しています。というか、Titleが必須フィールドなので、最初の呼び出しではTitleが含まれていないと失敗します。

テストの再現手順と期待値はHTMLです(このあたり)。注意点がいくつかあります。

  • HTMLの記号はエスケープする( < > "など)
  • (対応していないけど)改行があった場合、<br/>などのタグに置き換える。
  • (対応していないけど)色も同様

普通に一行で済むような手順と期待値であれば前述の関数で変換できるはずです。

サンプル扱いですが、もしよかったら動かしてみてください。Functionsでうまく動いていない問題は急ぎでなんとか…。

Azure DevOps 2020/6/1の更新

ちょっとde:codeのパーソナルスポンサー用ツールの準備に時間を取られていて、翻訳が遅くなりました。いつも通りSprint 170のリリースノートの翻訳を行いました。オリジナルはこちらから読んでください。

docs.microsoft.com

Work Itemの移動にルールが設定できるのは以前のオンラインセミナーで紹介しましたが、実際変更すると、どのルールに抵触したのか分かりづらいのが問題でした。今回、どのルールに違反したのかクリックすれば表示されるようになるそうです。

kkamegawa.hatenablog.jp

GitHub packagesを参照できるようになったり、Azure Artifactsでupstreamを無効化すると教えてくれるようになったり、軽量な認証タスクが増えたりと小粒ながら困っていたポイントが改良されているのはいいですね。

Ubuntu 20.04LTSのHosted agentがプレビュー公開されました。Latestはまだ18.04ですが、試してみたい方は明示的に変更してみてください。まだ全てのツールセットが入っていないそうなので、ビルドはこけるかもしれません。おそらくUbuntu 20.04に対応してないからとかそういう理由でしょう。

ではまた三週間後。

Translate to Japanese to Azure DevOps release not…

Azure DevOps 2020/5/11の更新

Azure Pipelinesのマルチステージ機能が正式版(GA)になったそうで、一週間スプリントで公開されましたので、リリースノートを翻訳しました。オリジナルはこちらから読んでください。いつもの通り、下訳にdeepl使ったあと、手直ししています。

docs.microsoft.com

とうとうマルチステージCDがGAになりました。これからはYAMLのほうに投資が行われると思いますので、今から慣れましょう。私も四苦八苦しながら書いています。タスクそのものはタスクを追加するAssistantがあるので、GUI時代と変わらないんですけどね。長くなってきたらテンプレートにするとか、最初からデプロイとビルドは分けておきましょうとかいろいろあるとは思います。

ロールベースセキュリティが追加されたのとか、前々から(Ignite the tourでも)いってたサービス接続のプロジェクト間の共有とか、関連するパイプラインが見えるようになったとか、パイプラインをリソースとして定義すると特定のバージョンを(Gitのcherry-pickのように)使えるようになったとか、便利な機能が多いですね。

日本は全国で緊急事態宣言が解除されましたが、もう少しの間イベントはオンラインで、ということになりそうなので、6/6にでもマルチステージパイプラインについてまたイベントやろうかなと思っています。

ではまた三週間後。

Translate to Japanese to Azure DevOps release not…