kkamegawa's weblog

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

Azure DevOps 2022/9/12の更新

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

learn.microsoft.com

久しぶりにDevloper Communityのリクエストにお応えしたというリリースノートですね。いろいろ細かいところだけど「そうそう、これいるよね」という機能追加が多いです。特にパイプライン関係のfetchでタグの同期を無効にできるようになったとか、最後のコミットメッセージを非表示にできるようになったというのはうれしいです。

最後のコミットメッセージを非表示にできるようになったというのは何がうれしいのかちょっとわからないケースもあると思いますが、Azure Pipelinesを使う場合、ソースコードのレポジトリとパイプラインのGitレポジトリを異なるものにすることができます。

  • ソースコード : dev.azure.com/{org}/{project}/{sourcerepo}
  • パイプライン:dev.azure.com/{org}/{project}/{pipelinerepo}

パイプラインの試行錯誤でコミットログがどんどん増えるのが嫌だとか、ブランチとパイプラインのYAMLが混在していると悩ましいとか、パイプラインの編集ができる人を限定したいとか、ソースレポジトリに余計なもの(CIの定義そのものは本来余計なものです)いろいろメリットがあります。

そんな方法で分割していてもビルドのコミットログにはパイプラインのコミットログが出てしまい、ちょっと嫌な感じだったのですが、それが消せるようになったということです。

YAMLのテンプレート式でsplit / eachとかも環境変数のパースするときは大変便利ですね。

タグの同期のところ、オリジナルのリリースノートではちゃんとタブで切り替えられるようになっているのですが(markdownからhtmlを生成しているため)、素のmarkdownではそんなことができないので、ちょっと見苦しいですがごめんなさい。

Ubuntu 18.04のhosted imageの廃止が予告されました。計画的に停止されるので、使っている人は注意してください。チェックするスクリプトもあるので、使ってみてください。

ではまた三週間後。

translate to Japanese to Azure DevOps release not…

NAT Gatewayの削除をスクリプトで実施する

AzureのNAT GatewayをPowerShellスクリプトで削除しようとしたんですよ。

docs.microsoft.com

ご存知の通り、NAT Gatewayはこれで削除する前にPublic IPとサブネットからデタッチしないといけません。デタッチしていないと-forceをつけても失敗します。じゃあ デタッチしようとしてもスクリプトでやる方法がちょっとわからなかった。

docs.microsoft.com

最初サブネット追加する時のようにこれでいけるのかなと思ったけど、だめ。結局bicepでやらないとダメ?ということで書いてみました。

github.com

NAT GatewayのサブネットとPublic IPを消してやることでちゃんとそれぞれからデタッチされました。作る方はこっち

github.com

まぁ作る方は散々サンプルがあるからいいと思います。消す方はあまりなかったので備忘録的に。おそらく他にもLoad Balancerとかのサブネットにアタッチするものはこういう感じでやらないといけない気がします。逆にBastionやVPN gatewayなどの専用のサブネットを作るものは普通に消せますね。

あと、Azure Cloud Shellでやっていたからかどうかわかりませんが、remove-aznatgatewayremove-azpublicipaddressを連続で実行するとどちらか片方しか消せませんでした。仕方ないので、-azjobつけてバックグラウンドジョブにしてみたらどちらも消せました。

Azure DevOps 2022/8/12の更新

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

docs.microsoft.com

いつもにも増して…今回はUbuntu 22.04イメージが正式版に(ただしlatestではない)なったことと、18.04が非推奨になったことが大きいですかね。18.04を使っている人は意図的に停止される時間帯があるので、気づいたら修正しましょう。依存しているソフトがあるとなかなか難しいですが。

パイプラインをスケジュールビルドしている場合にスケジュールが破損(実行できないスケジュールになったとか?)した時のエラーメッセージを修正したそうです。わかりやすくなりそうですね。

リリースノートは短いのに時間かかっていた理由は不定期に更新されると見るのが辛いので、自動的にfetchして未翻訳のものがあったらissueに登録する、というスクリプトを思い腰上げて作っていたのですが、最後の詰めではまっていたからです。次回のリリースからは自動化されるといいなぁ…ではまた三週間後。

translate to Japanese to Azure DevOps release not…

Azure DevOps REST APIでタスクを作る

なんかやるたびに調べている気がするので自分用のメモ。

docs.microsoft.com

新しいのが好きなので、7.1 Previewです。結構頻繁に更新されているので、気が付いたら8.0とかになっているかもしれません。

$PATに作成したPersonal Access Tokenが格納されているとします。

docs.microsoft.com

権限はWork ItemsRead & writeがあれば大丈夫なはずです。

$organization = '{Your Organization}'
$Project = '{Your Project}'
$TaskName = '{Your Task Title}'
$PAT='{Your Personal Access Token}'
$TaskTitle=[System.Convert]::ToBase64String([System.Text.Encoding]::ASCII.GetBytes($TaskName))
$token = [System.Convert]::ToBase64String([System.Text.Encoding]::ASCII.GetBytes(":$PAT"))
$header = @{authorization = "Basic $token"}
$uri = 'https://dev.azure.com/$organization/$Project/_apis/wit/workitems/$User%20Story?api-version=7.1-preview.3'
$jsonbody="[
  {
    `"op`": `"add`",
    `"path`": `"/fields/System.Title`",
    `"value`": `"$TaskTitle`"
  }
]"
$json = Invoke-RestMethod -Uri $Uri -Method Post -ContentType "application/json-patch+json" -Headers $header -body $jsonbody

$uri のworkitemsに続く値はプロセステンプレートにあるタスクの種類になります。私のサンプルではAgileで作っているプロジェクトに対して発行しているので、User%20Storyですが、ScrumであればProduct%20Backlog%20Itemなどになります。空白も含まれるので、%20を忘れないように注意。

タスク名に日本語を使う場合、Base64 Encodingが必要です。

Azure Pipelinesから呼び出して、PATをLibraryに格納する場合(まぁしますよね)、":$PAT"ではなく、":$ENV:PAT"となります。

これは「作るだけ」なので、このAPIで作ってもタスクが作成されるだけになります。Iteration、Area、Assigned toなどの値はUpdateで更新していきます。

docs.microsoft.com

全部のフィールド設定するのは大変ですが、先ほどのBodyは配列指定ができるので、最初op:addの次の要素でほかの要素も指定すればいいはずです…また後で検証してみます。