kkamegawa's weblog

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

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の次の要素でほかの要素も指定すればいいはずです…また後で検証してみます。

Azure DevOps 2022/7/29の更新

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

docs.microsoft.com

今回はほとんどセキュリティ関係の修正、エージェントプールの非推奨もしくは廃止の話ですね。今まで特に古いクラッシックパイプラインで過剰な権限を持っていたのでちゃんと制限するようにした、という習性が多いですね。クラッシックなので廃止する方向なのかと思っていましたが、まだまだ使っている人多いのでしょうか。

macOS 10.15のエージェントプールを使っている人は移行予告の意図的な停止があるので、このスケジュールにあたってビルドに失敗した人は早めに移行しましょう。スクリプトも提供されているのでチェックもできますね。

今回は簡単ですが、また三週間後。

translate to Japanese to Azure DevOps release not…

クラウドストレージの「常に最新」問題は問題なのか

KDDIさんの会見そのものは未視聴ですが、会見ではこんな話があったそうで。

※ この話だけを取り上げるのでスレッドの一部だけですが、一連の話も読んでください

この話を知人にしたら「クラウドに置いているのは最新、ということだけどそれでは困っているという人がいる」ということでこの話を紹介されました。

ameblo.jp

Googleドライブの中にWordを置くと、Googleドキュメントに変換されるが、同時編集でなくても、自分以外の人がスペースを入れても、句点「。」を打ってもすぐに上書きされてしまう。

Microsoft製品だと、Teams(チームス)やSharepoint(シェアポイント)でデータを共有するが、これまたほんの些細な変更でもどんどん上書きされていってしまう。

こういうクラウド上にデータを置いて共同作業する

これをある組織では「タイトル(常に最新)」という名前の付け方をされている。

たとえば、「天野公演説明プレゼン(常に最新)」といった感じだ。

作業内容が保存されずに消えないことはありがたいが、大勢で寄ってたかって編集して、
”いやいや、そこは元のままで正しかったのに”とか
”誰じゃー、これ勝手に変えたのはーっ”
ということも起きる。

Microsoft 365付属のOfficeではOneDriveに保存している場合、自動保存がデフォルトでONになります。

support.microsoft.com

失敗してもCtrl+zで戻せばいいですが、「だいぶ前に戻したい」というときはこの履歴を使うのが便利です。

support.microsoft.com

無制限に戻せるわけではなく、会社などでは設定した上限までです。

support.microsoft.com

とはいえ、私の場合この機能常時使っていなくて、ドキュメントの構成を作って書く内容を大雑把に決めるところまでは自動保存をオフにしておいて、適宜Ctrl+Sで保存。これで内容的に満たしたからここから肉付けしようか、という段階になってから自動保存をONにします。まぁ大体習慣的なものというか。

上のお話のように「みんなで」ドキュメントを作り上げる場合、共同編集機能でドキュメントに招待します。

support.microsoft.com

私の場合、どこに置くかはこうしています。

  1. 最初からチームの成果物としてのドキュメントを作る→SharePoint / Teamsにアップする(自動的に編集権限つく)
  2. 個人の資料をレビューしてもらう→ 個人のOneDriveに入れて、他人は基本読み取り権限で招待。場合によっては編集権限つける

この「ノボちゃん」のブログ主は「みんなに勝手に編集されて困る」という話ですが、それはちょっとやり方が違うんじゃないかなと思います。

  1. まずある程度ドキュメントの大枠は誰かが作る
  2. グループとしての成果物であれば「みんなで時間を取って」同じ時間にドキュメントを同時に編集して、大体の完成までもっていく。海外の場合はつらいかもしれませんが。
  3. そこから先、Typo(誤変換、スペルミス)であれば「直したよー」と事後連絡でもいいけど、基本的には執筆責任者決めて、コメントで指摘する

support.microsoft.com

ちゃんとコメントはmentionも飛びます。今のOfficeはコメントを「解決」状態にできるので、コメント解決し忘れているところは未修正箇所ですね。ただ、Officeドキュメントだけだったら自分のタスクとして覚えられない、ということもあると思います。

そういう時はOneNoteを共有して、ドキュメントをリンクノートとして追加します。

support.microsoft.com

この辺が図入りでもう少し分かりやすいかな。

www.wanichan.com

ただこれでもOneNoteを忘れたらだめですよね。そういう時はOutlookタスクとして設定します。

support.microsoft.com

Outlookタスクは自動的にMicrosoft To Doのタスクとして登録されるので、Outlook, OneNote, To Do, Teams(のタスク)どれを開いても自分のタスクが確認可能です。

どうでもいい話:
これ昔 SharePoint 2007から2013までの時代、OneNote→SharePoint→Outlookとタスク一気通貫でできるかなぁと夢見たことあったんですよ。残念ながら当時はOutlook→OneNoteかOneNote→SharePointといった1ホップしかできなくてあきらめていたんですが、クラウドサービスになってやっと、という感じです。

まぁこうやって、同期(同じ場所、同じ時間)で一緒に作り上げるフェーズと非同期(思いついたときに)のフェーズでやり方を変えないと、余計な手間ばかりかかります。

どうしても編集させたくないのであれば明示的にチェックアウトすればほかの人が編集できなくなります。

support.microsoft.com

でもKDDIのように承認があるドキュメントだとどうするの?ということであれば、Power Automateで承認のワークフローを作って承認依頼ドキュメントリストに入れたら承認実施する、ということになるでしょうね。

docs.microsoft.com

承認されたドキュメントは承認済みへコピー/ 移動して常時そこのファイルを参照すればいいんじゃないでしょうか(もちろん編集権限はみんななし)。

Azure DevOps オンライン Vol.6 - 業務で必要なCIをみんなで考えようフォローアップ

はじめに

tfsug.connpass.com

たくさんの方に視聴・ご参加いただきありがとうございました。ちょっとうっとうしいTeams参加通知を消す編集に手間取りました。


www.youtube.com

資料はこちら。

speakerdeck.com

中村さんに作っていただいたプロジェクトはパブリックなのでいつでも見えます。貴重な事情を赤裸々に語っていただいてありがとうございました。参加してコメントいただいた皆さんもありがとうございました。ちょっと不手際でロビー待ちになっていたり、なかなか入れなかったりとすいません。録画にも出てしまっていたので、少し編集でごまかしています。

大きなカンファレンスでは割とキラキラした事例が多く、「うちは大丈夫なのか」と焦ることも多いと思いますが、そうじゃないところもまだまだ多いはずなので、安心して(?)少しずつでも改善していきましょう。

Twitterから寄せられた情報

知らなかったです。ありがとうございます。

セルフホストイメージ作るには

GitHub Actions / Azure Pipelinesで使われているイメージを作成するためのレポジトリはこちら。

github.com

Windowsのイメージだと6時間少々、Ubuntuだと2時間ちょっとでできるはずです。私はこのレポジトリをforkしてカスタマイズして不要なもの(古い.NET Coreや不要なDockerイメージ)とかを削っています。時間がかかるのでCIする場合、Hostedでは作れないので、selfhost用のイメージを作るにはまずローカルで作ってからになります。

モバイル CI/CDのApp Center

モバイルのCI/CDに特化したサービスであればVisual Studio App Centerがあります。これもバックエンドはAzure Pipelines / GitHub Actionsと同じです。CIするなら楽なんですが、最近サービス更新がちょっとされていないように見えるので現時点ではActions / Pipelinesを使ったほうがいいかもしれません。

azure.microsoft.com

一応ロードマップには「技術的負債が結構あり、対応しんどいけど、頑張っています」的なことが書かれています。

github.com

Azureサブスクリプションで使えるのでお支払い的には便利です。

Dependabot for Azure Pipelines

github.com

あと、パブリックにしていいものとか、歴史的事情でAzure Reposにあるけど、GitHubにも課金しているという人であればAzure Reposから定期的にGitHubへpushしてGitHubのDependabotに任せるという意見もありました😅。

Forkと契約形態

一応こういうやり方もあるよという話です。

kkamegawa.hatenablog.jp

請負で直接指示できないような場合、やはりプロジェクトを跨いだforkをするのがいいんじゃないかという話です。タスク管理もお互いでできるので割と要件を満たせると思います。

最後に

今回の配信はAzure Rock Starプログラムの支援をいただいています(セッション中いうの忘れていたので宣伝)。ありがとうございました。

www.microsoft.com