Azure DevOps 2019/8/12の更新

今回は時間があったので、割と早く翻訳が終わりました。というわけで、Sprint 156のリリースノートの翻訳です。オリジナルはこちらから読んでください。

docs.microsoft.com

今回は主に、Azure Boardsの機能強化が多かったですね。投票でコメントディスカッションにリアクションつけられるようになったのはGitHub的でうれしい人も多いんじゃないかなと思います。人によってはもうロールアウトされているようです。

グループメンバー向けにWork Itemのフィールドの一部を読み取り専用にするとか、必須にするとかはエンタープライズ向けにとても便利だと思います。運用は結構大変かと思いますが…。

同一Azure AD内にあるOrganizationのartifactsをupstreamソースとして設定できるのもうれしいですね。どこかの部門が部品やセキュリティチェック通ったパッケージのみ集中管理できるようになるので、効率的になりそうです。

DockerイメージをいちいちACRにプッシュしなくても、そのままAKSへデプロイできるようになるのは特定のブランチでのビルドはACRにプッシュしたくないという、テスト用に便利そうです。

イントラネットで自前のビルドエージェントを運用していて、outboundのアクセス制限をかけている組織はpublish test resultsタスクでエラーが出ることがあるそうです。https://*.vstmrblob.vsassets.io への通信を許可するようにしてください。Azure DevOpsが提供するMicrosoft-hostedエージェントに関しては必要ありません。

長い間全く手が入らなかったAzure TestsもようやくUIの刷新から手を付けるようになったようです。楽しみですね。

リリースノートとは関係ないですが、プレビュー版のEdgeを使った場合、Azure DevOpsのサイトをアプリとしてインストールできるようになります。メニューの…から「アプリ」→「このサイトをアプリとしてインストール」を選んでみてください。たぶんAzure DevOps Server 2019でもできるはずです(もしかしたら今プレビューのUpdate 1 RCじゃないとダメかもしれませんが)。

ではまた三週間後。

Translate to Japanese to Azure DevOps release note ...

Azure DevOps 2019/7/22の更新

ちょっといろいろあって、翻訳滞っているうちに、Sprint 156がリリースされましたが、Sprint 155のリリースノートの翻訳を行いました。オリジナルはこちらから読んでください。

docs.microsoft.com

今回もいろいろ強化が行われていますが、Sprint 155リリースの後、4つほどの新機能がしれっとリリースノートに滑り込まれています。原文のFeaturesの一覧には載っていませんが、翻訳の方には付けています。

具体的にはこの辺です。

• Pipelineの変数グループと変数を管理するコマンドのサポート
• Pipelineのキャッシュ(パブリックプレビュー)
• PRブランチ用のパイプラインを実行する
• 最初のパイプライン実行をスキップする
• サービスエンドポイントコマンドの強化

あと、リリースノートが最初に公開されたとき、Google Analytics拡張機能はデッドリンクだったので一度リンク削除されていましたが、正式公開されたので、訳文ではリンクをつけています。

Pipelineのキャッシュはすでにブログで公開されていたので、ご存じかと思いますが、「最初のパイプラインをスキップする」のは非常に欲しい機能だったので(これいつも鶏と卵の関係でイライラしてた)、非常に助かります。

あと、ブランチを新規作成した時にCIが実行されてしまうというのもいつもイライラしていたので、これまた非常に助かります。ただし、GitLab Flowのような「新しくブランチを作ることにより、CIをトリガーする」挙動に依存しているフローでは困ることも分かっています。これはたぶん設定か何かで改善されるのでしょう。

今まで乱立していたHosted poolでどれが並列度を消費しているのかわかりづらかったので、今はAzure Pipelinesという仮想的なhosted poolにまとめられることになりました。従来の設定はリダイレクトされるので、特に変更する必要はありません。これは大規模環境で便利だろうと思います。

GitHubアカウントを持っている人はGitHubアカウントでコラボレーターとして招待できるようになったのもいいですね。

あと、Azure DevOpsには間接的に関係ありますが、GitHub ActionでのCI/CDがサポートされました。こちらのバックエンドはAzure Pipelinesだそうです。エージェントのみforkしているようですね。

次のSprint 156のリリースノートの翻訳はなるべく早く出します…。

Translate to Japanese to Azure DevOps release note ...

Azure DevOpsプロジェクトのプロセステンプレートを変更する

長い間リクエストが多かったAzure DevOpsのプロジェクトプロセスがついに変更できることになりました。Sprint 154からの新機能ですが、おそらくすでに全Organizationへ展開されているはずです。

私も古いプロジェクトはAgileやScrumで作っていたのですが、個人プロジェクトならBasicでいいかなぁと思っていたのでとても助かります。ではやってみましょう。

• https://dev.azure.com/{organization}/settings/process?a=all へアクセスします。
• 変更したいプロセスのプロジェクトを開き、…リーダーからChange processを選びます。

変更したいプロセスを選びます。AgileからScrumを選んでみます。

実行すると…失敗します。これはなぜかというと、Agileにあって、ScrumにないWork Item Typeがあるためです。

docs.microsoft.com

これはどのプロセスでも同じです。解決するには、移行先のプロセスから継承したプロセスを作り、移行元にあるWork Item Typeを作る必要があります。

Agile→Scrumの場合、Issue, User Storyという種類が存在しないので、作る必要があります。

今度はScrum→Basicでやってみます。Basicを継承してInherit Basicというプロセスを作ります。

上と同じ手順でScrum→Basicにすると、BugとProduct Backlog Itemがないので、作ります。

ScrumにしかないProduct Backlogはそのまんま標準のProduct Backlogという名前でレイアウトもそのまま作ります。まだ全部見ているわけではないですが、標準のコントロールを使っているだけであれば、同じ名前のWork Item Typeだけ作ればいいんじゃないかなと思います。

以前のWork Itemをそのまま扱うのであれば、厳密にStatusやRuleも設定したほうがいいでしょう。

Bugも同じように作って、Inherit Basicができました。これでもう一度移行しますが、今度はBasicではなく、Inherit Basicへ移行します。

今度はうまくいきました！もちろんこれはWork Itemがすでにある場合のみ発生する現象で、Work Itemが存在しないプロジェクトであれば、このようなエラーもなく、移行できます。作って「あ、間違えた」といううっかりであれば継承しなくても大丈夫です。

移行した後は、継承元にあったProduct Backlog Itemなどは使わず、移行先のWork Item Typeのみ使用してください。

docs.microsoft.com

docs.microsoft.com

(追記)
MSの中の人がプロセステンプレートを編集するCLIツールを公開しています。

github.com

issueの中に「特定のWork Itemを別のプロセステンプレートへコピーする」っての登録しているので、そのうちこのCLIで簡単に複製できるんじゃないかなと思います。

github.com

Azure DevOps 2019/7/1の更新

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

docs.microsoft.com

今回はいろいろ強化店が多いですね。UIの変更も多いようです。Test Planプレビューはリリースされているようなことを書いていますが、私のOrganizationにはまだ来ていないようです。ゆっくり待ってみます。

Work Itemのlive updateはいいですね。多人数のプロジェクトではとても役立つと思います。

インスタントサーチも便利です。今までいちいち検索していたのは大変でした。

プロジェクトのプロセス変更も長い間待っていたので、大変うれしい。とりあえず個人プロジェクトは全部Basicにしようかなぁと思っています。

今までわかりづらかったHosted poolの管理が仮想的なプール一つにまとめられてわかりやすくなるのもよさそうです。

今までFeature Flagを管理するサービスは LaunchDarklyが有名でしたがOptimizelyもサポートするそうです。

そのほかの機能強化も便利そうなものがたくさんです。ではまた三週間後。

Translate to Japanese to Azure DevOps release note ...