Skip to content

Instantly share code, notes, and snippets.

@kkamegawa
Created October 6, 2019 22:18
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save kkamegawa/e26364d6ce7c0d30bb662df368a18e6e to your computer and use it in GitHub Desktop.
Save kkamegawa/e26364d6ce7c0d30bb662df368a18e6e to your computer and use it in GitHub Desktop.
Translate to Japanese to Azure DevOps release notes(unofficial) from https://docs.microsoft.com/en-us/azure/devops/release-notes/2019/sprint-158-update

ユーザー割り当てベースの課金、既定のアクセスレベルと一日単位の課金 - Sprint 158 Update

Azure DevOpsのSprint 158 Updateで、ユーザー割り当てベースの課金を追加しました。この機能を使用すると、ユーザーを追加または削除すると、BasicまたはBasic + Test Planライセンスの数が変わります。これは、使用しているライセンスに対してのみ支払うことを意味します。また、Organizationへ追加された新しいユーザーに完全な基本アクセスを許可するか、利害関係者の制限付き/無料アクセスを許可するかを選択できる新しい設定を追加しました。

さらに、毎月の請求から毎日の請求に切り替えました。これは、ユーザーに数週間または数日間の有料アクセスを許可した場合、1か月ではなく、有料アクセスが割り当てられた時間にのみ料金を支払うことを意味します。

詳細については、以下の機能リストをご覧ください。

General:

Azure Boards:

Azure Repos:

Azure Pipelines:

Azure Test Plans:

Reporting:

Wiki:

課金をユーザー割り当て単位に変更しました

今回の更新では、ユーザー割り当てに基づく請求が追加されました。Organizationが割り当て可能な有料のBasicまたはBasic + Test Planライセンスの数を増減する代わりに、ユーザーを追加または削除したり、アクセスレベルを変更したりすると自動的に割り当てが発生します。これは、使用しているユーザーの数よりも多くのライセンスを支払う必要がないことを意味し、アクセスレベルの割り当ての自動化をはるかに簡単にします。たとえば、今まではグループルールを設定して、チームに自動的に参加する新しいユーザーに割り当てるアクセスレベルを制御することができました。これまでは、有料の追加ライセンスがまだ誰にも割り当てられていなかった場合にのみ機能していたため、使い果たした場合、group ruleは失敗していました。今後、請求に使用するAzureサブスクリプションがアクティブである限り、この種のエラーは発生しなくなります。

新規ユーザーへのデフォルトアクセスレベルの設定をサポート

organizationへ追加された新しいユーザーに対してBasicアクセスを許可するか、制限付き/無料アクセスであるStakeholderで許可するかを選択できる新しい設定も追加しました。以前は、割り当てられていないBasicライセンスがある場合、新しいユーザーがBasicライセンスを取得し、利用できなかった場合はStakeholderを取得しました。すべてのorganizationは、デフォルトのアクセスレベルをStakeholderに設定して開始するため、新規ユーザーに予期しない料金が発生することはありません。通常、organizationが追加の未割り当てライセンスを保持しているため、プロジェクトに追加された新しいユーザーが完全なBasicアクセス権を取得した場合は、必ずデフォルトアクセスレベルをBasicに変更してください。

Default access level for new users

日次課金

割り当てベースの請求への変更の一環として、月単位から日単位の請求にも切り替えました。今回の更新で、ユーザーに数週間または数日間の有料アクセスを許可すると、1か月ではなく、有料アクセスが割り当てられた時間にのみ支払います。organizationを毎月の請求から毎日の請求に切り替えると、次のAzureの請求は以前よりも低くなる可能性があります。全員1か月間使用した費用が累積されると、翌月の支払いは通常に戻ります。

Organizationおよびプロジェクトの権限管理の外観が新しくなり、パフォーマンスが向上しました。今回の更新で強制的にページを更新することなく、新しいグループメンバーが追加されるたびにリストへ表示されます。Organization Settingsに移動してみてください。

New UI to manage organization and project permission

ロールアップは、カスタムフィールドを含む任意のフィールドで実行できるようになりました。ロールアップ列を追加する場合、クイックリストからロールアップ列を選択できますが、既定のプロセステンプレートに含まれない数値フィールドをロールアップする場合、独自に構成できます。例を紹介します。

  1. バックログでColumn optionsをクリックします。次に、パネルでConfigure custom rollupをクリックし、カスタムロールアップを構成します。 custom rollup
  2. Progress BarTotalを選択します。
  3. 作業項目タイプまたはバックログレベルを選択します(通常、バックログはいくつかの作業項目タイプを集約します)。
  4. 集約タイプを選択します。Count of work itemsまたはSum。Sumの場合、集計するフィールドを選択する必要があります。
  5. OKボタンをクリックすると、列オプションパネルに戻り、新しいカスタム列を並べ替えることができます。 New custom column

OKをクリックすると、カスタム列を編集できないことに注意してください。変更する必要がある場合は、カスタム列を削除し、必要に応じて別の列を追加します。

継承されたルールエンジンに新しいルールを追加することで、作業項目フォームのフィールドを非表示とできるようにしました。このルールは、ユーザーグループメンバーシップに基づいてフィールドを非表示にします。たとえば、ユーザーが"product owner"グループに属している場合、開発者固有のフィールドを非表示にできます。詳細については、こちらのドキュメントをご覧ください。

お客様皆様のチームに関連する作業項目を最新の状態に保つことは非常に重要です。チームが協力してプロジェクトを順調に進め、適切な関係者全員が関与するようにします。ただし、利害関係者はそれぞれの立場でさまざまな取り組みに色々なレベルの投資を行っており、作業項目のステータスをフォローする能力にそれが反映されるべきだと考えています。

これまでは、行われた変更に関する通知を受け取りたい場合、作業項目をフォローして、作業項目に加えられたすべての変更に関する電子メール通知を受け取っていました。みなさんのフィードバックを考慮した結果、私たちはすべての利害関係者にとってより柔軟に作業項目がフォローできるようにしました。今回の更新から、作業項目の右上隅のFollowボタンの横に新しい設定ボタンが表示されます。これにより、フォローアップオプションを設定できるポップアップが表示されます。

Custom work item notification settings

Notification Settingsから、3つの通知オプションの選択ができます。まず、あなたは完全に通知を無効にできます。第二に、すべての作業項目の変更に関する通知を完全に受け取る設定ができます。最後に、プロジェクトにとってもっとも重要だと考える作業項目変更イベントの一部についてのみ通知を樹脂するという選択ができます。1つだけ、または3つすべてのオプションを選択できます。これにより、チームメンバーはより高いレベルで選択した作業項目のみが追跡できるようになるため、変更が行われるたびに気が散ることはありません。この機能により、不必要な電子メールを排除し、手元の重要なタスクに集中できます。

Notification Settings

作業項目フォームのDeploymentコントロールのプレビューをリリースできることを嬉しく思います。このコントロールは、作業項目をリリースにリンクし、作業項目が展開された場所を簡単に追跡できるようにします。詳細については、こちらのドキュメントをご覧ください。

Link work items to deployments

これまで、AKS Deployment CenterからAzure Pipelinesを構成する際に、Azure Resource Manager Connectionを使用していました。作成された接続は、パイプラインが構成されたネームスペースだけでなく、クラスター全体にアクセスできました。今回の更新により、パイプラインはサービスアカウントベースの認証を使用してクラスターに接続し、パイプラインに関連付けられた名前空間にのみアクセスできるようになります。

新しいPreviewボタンを使用して、マークダウンファイルのプレビューが確認できるようになりました。さらに、Viewボタンを選択することにより、Side-by-side diffからファイルの完全なコンテンツを表示できます。

Preview Markdown files

ポリシーは、チームのコード品質と変更管理基準を強化します。これまで、自動ビルドのビルド保存有効期限ポリシーを設定できていました。今回の更新により、手動ビルドに対しても、ビルドの有効期限ポリシーを設定できるようになりました。

Build policy expiration for manual builds

管理者はプッシュポリシーを設定して、コミット作者の電子メールが提供されたパターンに一致しないコミットがリポジトリへプッシュできないように設定できるようになりました。

Add a policy to block commits based on the commit author email

この機能は、Developer Communityからの提案にあった同様のエクスペリエンスを提供するために、優先順位が付けられました。このチケットは引き続きオープンのままにしているので、他の種類のプッシュポリシーが必要な場合は私たちに教えてください。

注意事項

この機能を試す場合、Multi-stage pipelinesのプレビュー機能を有効にしてください。

マルチステージパイプラインでもっとも要求される機能の1つは、失敗したステージを最初からやり直すことなく再試行できるという点です。今回の更新では、この機能の大部分を追加しています。

実行が失敗したときにパイプラインステージを再試行できるようになりました。最初の試行で失敗したジョブと、失敗したジョブに推移的に依存するジョブはすべて再試行されます。

これにより、いくつかの方法で時間を節約できます。たとえば、ステージで複数のジョブを実行する場合、各ステージで異なるプラットフォームにおいてテストの実行が可能です。あるプラットフォームでのテストが失敗し、他のプラットフォームでテストが成功した場合、成功したジョブを再実行しないことで時間を節約できます。別の例として、不安定なネットワーク接続のために展開ステージが失敗するかもしれません。そのステージを再試行すると、別のビルドを作成する必要がなくなるため、時間を節約できます。

この機能にはいくつかの既知のギャップがあります。たとえば、明示的にキャンセルしたステージを再試行することはできません。将来のアップデートでこれらのギャップを埋めるために取り組んでいます。

注意事項

この機能を試す場合、Multi-stage pipelinesのプレビュー機能を有効にしてください。

マルチステージYAMLパイプラインの改善を続けています。今回の更新により、サービス接続とエージェントプールの承認の構成が可能になりました。承認については、インフラストラクチャの所有者と開発者の間の役割の分離に従います。environments、service connections、agent poolsなどのリソースで承認を構成することにより、リソースを使用するすべてのパイプライン実行で最初に承認が必要になることが保証されます。

このエクスペリエンスは、environmentsの承認の構成に似ています。ステージで参照されているリソースの承認が保留中の場合、パイプラインの実行は、パイプラインが手動で承認されるまで待機します。

Enhancements to approvals in YAML pipelines

テストデータ概要

アプリケーションでのコンテナーの使用が増加しているため、堅牢なテストと検証の必要性が高まっています。Azure Pipelinesは、Container Structure Testsのサポートを開始しました。このフレームワークは、コンテナーの内容と構造を検証する便利で強力な方法を提供します。

一緒に実行できる4つのカテゴリのテストに基づいて、イメージの構造を検証できます:コマンドテスト、ファイル存在テスト、ファイルコンテンツテスト、メタデータテスト。パイプラインの結果を使用して、go/no go決定を行うことができます。エラーメッセージと共にパイプライン実行でテストデータを利用できるため、障害のトラブルシューティングを改善できます。

構成ファイルとイメージの詳細を入力します

Container structure testing support in Azure

テストデータと概要

Test data and summary

7月に、検出、レポート、および解決を行うエンドツーエンドのライフサイクルをサポートするために、不安定なテスト(flaky test:ネットワーク、データベースなど環境に依存して結果が安定しないテスト)管理を導入しました。さらに強化するために、不安定なテストバグ管理と解決策を追加しています。

不安定なテストの調査中に、Bugアクションを使用してバグを作成、開発者に割り当てて、不安定なテストの根本原因をさらに調査できます。バグレポートには、エラーメッセージ、スタックトレース、テストに関連するその他の情報など、パイプラインに関する情報が含まれています。

バグレポートが解決またはクローズされると、テストのフレーク解除のマークが自動的に解除されます。

YAMLベースパイプラインのマルチステージ

注意事項

この機能を試す場合、Multi-stage pipelinesのプレビュー機能を有効にしてください。

SlackおよびMicrosoft Teams用のAzure Pipelinesアプリは、CIおよびCD用のマルチステージYAMLパイプラインをサポートを開始しました。この機能強化により、YAMLパイプラインに関連するさまざまなイベントに関する通知が届きます。

Multi-stage YAML based pipelins

マルチステージYAMLパイプラインでサポートされるイベント

  • Run state changed(実行状態がの変更された)
  • Run stage state changed(ステージの実行状態が変更された)
  • Run stage waiting for approval(ステージが承認の待ち状態になった)
  • Run stage approval completed(ステージの承認が完了した)

Support events

URL展開とメッセージ拡張機能

Microsoft Teams用のAzure Pipelinesアプリ用のメッセージング拡張機能を追加しました。今回の更新で、パイプラインを検索し、パイプラインに関する関連する詳細をチャネル内のカードとして共有できます。URL展開は、パイプラインに関する議論を開始し、意味のあるコンテキストの会話を行うのに役立ちます。

URL unfurling and messaging extensions

Azure PipelinesでホストしているAzure PipelinesのVMイメージを更新しました。今回の更新のハイライトを以下に紹介します。

  • Ubuntu Ubuntu 16.04, Ubuntu 18.04, VS2017, VS2019にGo 1.13を追加しました。Go 1.12はデフォルトで残っています。
  • Ubuntu 16.04, Ubuntu 18.04, VS2017, VS2019にAndroid SDKとBuild tools 29を追加しました。
  • VS2017とVS2019にAzモジュール2.6.0を追加しました。
  • 多くのバグを修正しました。

細心のリリースの詳細に関してはこちらから確認できます。

注意事項

Ruby 2.3は2019/3/31にサポート終了したため、すべてのイメージから取り除かれます。

Open Policy Agentは、オープンソースの汎用ポリシーエンジンであり、統合されたコンテキスト認識ポリシーの実施を可能にします。今回の強化でOpen Policy Agentインストーラータスクを追加しました。とくにこれは、コードプロバイダーとしてのインフラストラクチャに関するパイプラインでのポリシーの実施に役立ちます。

たとえば、Open Policy Agentは、RegoポリシーファイルとTerraform計画をパイプラインで評価できます。

task: OpenPolicyAgentInstaller@0
    inputs:
          opaVersion: '0.13.5'

パイプラインデコレータを使用すると、すべてのジョブの最初と最後にステップを追加できます。これは、Organization内のすべてのパイプラインに適用されるため、単一の定義にステップを追加することとは異なります。

ビルドとYAMLパイプライン用のデコレータをサポートしており、顧客はそれらを使用してジョブのステップを集中管理しています。現在、サポートを拡張してパイプラインもリリースしています。拡張機能を作成して、新しいコントリビューションポイントをターゲットとするステップを追加できます。これらのステップは、リリースパイプラインのすべてのエージェントジョブに追加されます。

計画、オーサリング、実行、および追跡機能のほとんどが、新しいテスト計画ページで利用できるようになりました。新しいページに対するフィードバックを提供できるように、すべてのTest Plansユーザーに対して有効化しています。まだ新しいページではすべての機能を提供していないため、次のスプリントで以前のTest Plansで提供していた残りのいくつかの機能を提供する予定です。みなさんは必要に応じて、Preview FeaturesメニューのTest Plansでプレビューページを無効にできます。詳細はこちらをご覧ください。

スプリントバーンダウンがストーリーごとのバーンダウンをサポートを開始します。これは、Developer Communityからのフィードバックに基づいたものです。

SprintハブからAnalyticsタブを選択します。次に、レポートを次のように構成します。

  1. ストーリーバックログを選択
  2. バーンダウンでSum of Story Pointsを選択します

inline sprint burndown using story poings

Wikiページのリンクを共有するために複数行のURLを使用する必要がなくなりました。URLのページIDを利用したパラメーターを削除することで、URLを短くして読みやすくしています。

URLの新しい構造は次のようになります。

https://dev.azure.com/{accountName}/{projectName}/_wiki/wikis/{wikiName}/{pageId}/{readableWiki PageName}

これは、Welcome to Azure DevOps Wikiページの新しいURLの例です。

https://dev.azure.com/microsoft/ AzureDevOps/_wiki/wikis/AzureDevOps.wiki/1/Welcome-to-Azure-DevOps-Wiki

これは、Developer Communityでのこの機能提案チケットに基づいて優先順位が付けられました。

wikiページにmermaid diagramsを挿入するためのサポートを追加しました。Azure DevOps Wikiで、設計図のフローチャート、シーケンス図を作成、編集、管理し、計画図のガント図を追加できるようになりました。

Mermaid diagram support in wiki

これは、Developer Communityでのこの機能提案チケットに基づいて優先順位が付けられました。 mermaid diagramsの詳細については、こちらのドキュメントをご覧ください。

注意事項

ここで議論されている機能は今後二~三週にわたって順次展開されます。

これらの新機能を読んだ後、次のリンクからぜひご自身でAzure DevOpsサービスを体験してみてください。

Go to Azure DevOps Services

これらの機能についてどう思っているかお聞きしたいと思います。 フィードバックメニューを使用して問題を報告するか、提案を提出してください。

Make a suggestion

アドバイスや回答を必要とする質問がある場合、Stack Overflowコミュニティで聞いてください。

ありがとうございました。

Ravi Shanker

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment