Translate to Japanese to Azure DevOps release notes(unofficial) from https://docs.microsoft.com/en-us/azure/devops/release-notes/2020/sprint-174-update

2020-Aug-24-Azure-DevOps-jajp.md

YAMLプレビューAPIの強化とユニバーサルパッケージ用のupstreamソースの構成 - Sprint 174

このスプリントでは、ファイナライズされたYAMLボディを取得するための新しいAPIエンドポイントを展開しています。また、このリリースでユニバーサルパッケージ用のupsteamソースを設定できる機能を追加したことについて発表できることに興奮しています。

詳細は以下の新機能一覧をご覧ください。

Features

Azure Boards

• バックログとボードにシステムワークタイプの追加が可能になりました
• 監査ログイベントの追跡を強化しました
• Azure Boards GitHubアプリケーションの上限を解除しました(private preview)
• pull requestをマージする時に作業項目の状態のカスタマイズができるようになります(private preview)

Azure Pipelines

• Pipelinesイメージの案内
• エージェントログのアップロード機能を改善しました
• コンテナーでマウントしたボリュームを読み取り専用にするオプションを提供します
• コンテナーの開始と終了を自分で管理できるようになりました
• 各ステップでタスクバンドルを展開する
• リリースセキュリティの改善のために、アクセストークンの範囲の制限がかけられるようになります
• YAMLプレビューAPIを強化しました

Azure Artifacts

• Universal Package用のupstreamソースを構成できるようになりました
• Mavenパッケージを更新するREST APIが一般提供されました

Azure Boards

バックログとボードにシステムワークタイプの追加が可能になりました

選択したバックログレベルにシステムのワークアイテムタイプを追加できる機能のプライベートプレビューを開始しました。歴史的にこれらのワークアイテムタイプは、クエリからのみ利用可能でした。

Process	Work Item Type
Agile	Issue
Scrum	Impediment
CMMI	Change Request
	Issue
	Review
	Risk

この機能がプレビューから外れ、すべてのorganizationで一般的に利用できるようになったことをお知らせします。簡単にシステムワークアイテムタイプをバックログレベルへ追加できます。カスタムプロセスに入り、the Backlog Levels tabをクリックするだけです。選択したバックログレベル（例：要件バックログ）を選択し、Editオプションを選択します。次に、作業項目タイプを追加します。

監査ログイベントの追跡を強化しました

監査ログに新しいイベントを追加し、お客様がプロセス関連の変更をよりよく追跡できるようにしました。ピックリストの値が変更されるたびにイベントが記録されます。通常、ピックリストフィールドの変更は、プロセスに行われる最も一般的な変更です。組織の管理者がこの新しいイベントを使用することで、いつ、誰がこれらのフィールドに変更を加えたかをよりよく追跡することができます。

Azure Boards GitHubアプリケーションの上限を解除しました(private preview)

GitHubマーケットプレイスのAzure Boardsアプリケーションを利用している場合、接続できるGitHubリポジトリは100個までと制限されています。これは、100以上のリポジトリを十分に持つことができる大規模な組織にとってはブロッカーになります。このスプリントでは、Azure BoardsがGitHubリポジトリに接続する方法を変更して、100以上のリポジトリへの接続を可能にしました。現在100レポの上限を超えている場合は、お知らせいただければ、その上限を増やしてブロックを解除する機能を有効にすることができます。組織名 (dev.azure.com/{organization}) を直接メールでお知らせください。

pull requestをマージする時に作業項目の状態のカスタマイズができるようになります(private preview)

すべてのワークフローが同じではありません。pull requestが完了したときに、関連するワークアイテムをクローズしたいと考えているお客様もいます。また、ワークアイテムを別の状態に設定して、閉じる前に検証を行いたいと考えているお客様もいます。この両方を許容すべきです。

Sprint 174から、pull requestがマージされて完了したときに、作業項目を希望の状態に設定できるようにする新機能を導入しました。これを行うには、pull requestの説明をスキャンして、作業項目の#mentionが続く状態値を探します。この例では、2つのユーザーストーリーを解決済みに設定し、2つのタスクを終了させています。

この機能は長い間待ち望まれていたもので、私たちはあなたの考えを見て興奮しています。最初に、私たちはpull requestの説明をスキャンしているだけで、ユーザーインターフェイスの変更は含まれていません。私たちは、さらなる投資を行う前に、まずあなたのフィードバックを得たいと考えています。

プライベートプレビューへの参加に興味のある方は、直接メールでご連絡ください。あなたのorganization (dev.azure.com/{organization}) を忘れずに記載してください。

Azure Pipelines

Pipelinesイメージの案内

注意
Azure Pipelinesイメージは、ユーザーに可能な限り最高の体験を提供するために継続的に更新されます。これらの定期的な更新は、主にバグや古くなったソフトウェアへの対処を目的としています。多くの場合、パイプラインへの影響はありませんが、必ずしもそうとは限りません。パイプラインが、イメージ上で削除または更新されたソフトウェアに依存している場合、影響を受ける可能性があります。 私たちのWindows, Linux, macOSのイメージの更新については、以下の告知をご覧ください。

Windows 2016

Windows 2019

Ubuntu 16.04

Ubuntu 18.04

Ubuntu 20.04

MacOS 10.15

今後の（プレリリースを含む）リリースノートと、デプロイの変更点は以下を参照するか、リリースノートを購読してください。

Release notes

エージェントログのアップロード機能を改善しました

エージェントがAzure Pipelinesサーバーとの通信を停止すると、実行していたジョブは放棄されます。ストリーミングされたコンソールログを見ていた場合、エージェントが応答しなくなる直前に何をしていたかの手がかりが得られたかもしれません。しかし、そうではなかったり、ページを更新した場合、それらのコンソールログは消えています。このリリースでは、エージェントが完全なログを送信する前に応答を停止した場合、次善の策としてコンソールログを保持します。コンソールログは1行あたり1000文字に制限されており、時折不完全な状態になることがありますが、何も表示されないよりはずっと役に立ちます！これらのログを調べることは、あなた自身のパイプラインのトラブルシューティングに役立つかもしれませんし、当社のサポートエンジニアがトラブルシューティングを支援する際の助けになることは間違いありません。

コンテナーでマウントしたボリュームを読み取り専用にするオプションを提供します

Azure Pipelinesでコンテナージョブを実行すると、ワークスペース、タスク、およびその他のマテリアルを含む複数のボリュームがボリュームとしてマッピングされます。これらのボリュームは、デフォルトで読み取り/書き込みアクセスが可能になっています。セキュリティを高めるために、YAMLでコンテナーの仕様を変更することで、ボリュームを読み取り専用でマウントできます。mountReadOnlyの下の各キーは、読み取り専用のためにtrueに設定できます（デフォルトはfalseです）。

Copy
resources:
  containers:
    - container: example
      image: ubuntu:18.04
      mountReadOnly:
        externals: true
        tasks: true
        tools: true
        work: false

コンテナーの開始と終了を自分で管理できるようになりました

一般的には、Azure Pipelinesにジョブやサービスコンテナーのライフサイクルを管理させることをお勧めします。しかし、いくつかの珍しいシナリオでは、自分でそれらを開始や停止したい場合があります。今回のリリースでは、その機能をDockerタスクに組み込みました。

新しい機能を使う場合のパイプラインサンプルです。

resources:
  containers:
    - container: builder
      image: ubuntu:18.04
steps:
  - script: echo "I can run inside the container (it starts by default)"
    target:
      container: builder
  - task: Docker@2
    inputs:
      command: stop
      container: builder
# if any step tried to run in the container here, it would fail

また、コンテナーのリストをパイプライン変数Agent.ContainerMappingにインクルードしています。これは、例えばスクリプトでコンテナーのリストを検査したい場合などに使用できます。これには、エージェントが管理するコンテナーIDにリソース名（上の例では "builder"）をマッピングした文字列化されたJSONオブジェクトが含まれています。

各ステップでタスクバンドルを展開する

エージェントがジョブを実行すると、まず、ジョブのステップで必要とされるすべてのタスクバンドルをダウンロードします。通常、パフォーマンスのために、タスクが複数のステップで使用される場合でも、ジョブ単位で一度だけタスクを展開します。信頼されていないコードが展開された内容を変更することを懸念している場合、パフォーマンスを少し犠牲にする代わりに、エージェントでの使用毎にタスクの展開を行います。このモードを有効にするには、エージェントを設定する際に--alwaysextracttaskを渡してください。

リリースセキュリティの改善のために、アクセストークンの範囲の制限がかけられるようになります

Azure Pipelinesのセキュリティ設定を強化するためのイニシアチブを構築し、リリースのアクセストークンの範囲を制限できるようになります。

リリースで実行されるすべてのジョブは、アクセストークンを取得します。アクセストークンは、タスクやスクリプトがAzure DevOpsへコールバックする際に使用されます。例えば、ソースコードの取得、成果物のダウンロード、ログのアップロード、テスト結果のアップロード、Azure DevOpsへのREST呼び出しなどにアクセストークンを使用します。新しいアクセストークンはジョブごとに生成され、ジョブが完了すると失効します。

今回のアップデートでは、アクセストークンの範囲を制限することでパイプラインのセキュリティが向上します。従来のリリースにも同様の機能を拡張しています。

この機能は、新しいプロジェクトやorganizationではデフォルトでオンになります。既存のorganizationの場合は、Settings > Pipelines > Settings. > Limit job authorization scope to current project for release pipelinesで有効にする必要があります。リリースパイプラインの場合は、ジョブ認証範囲を現在のプロジェクトに制限します。詳細はこちらを参照してください。

YAMLプレビューAPIを強化しました

数回前のスプリントでは、パイプラインを実行せずにパイプラインの完全なYAMLをプレビューする機能を紹介しました。今回のアップデートでは、プレビュー機能のための専用の新しいURLを作成しました。https://dev.azure.com/{org}/{project}/_apis/pipelines/{pipelineId}/previewにPOSTして、最終的なYAMLボディを取得できるようになりました。この新しいAPIは実行をキューイングするのと同じパラメーターを取りますが、"Queue builds"パーミッションを必要としなくなりました。

Azure Artifacts

Universal Package用のupstreamソースを構成できるようになりました

Azure Artifactsフィードを設定して、必要に応じてupsteamソースからUniversal Packagesを自動的にダウンロードできるようになりました。

以前は、NuGet、Python、Maven、およびnpmパッケージのためにフィード上でupsteamソースを設定することはできましたが、Universal Packagesには設定できませんでした。これは、Universal Packagesに使用されているストレージ技術の違いによるもので、他のサポートされているパッケージタイプよりもはるかに大きなパッケージをサポートしています。

他のパッケージタイプの場合と同じ方法で、ユニバーサルパッケージのupsteamソースを設定できるようになりました。フィード設定を開き、 Upstream sources → Add upstream source →をクリックして、適切なソースタイプを選択します。次のビューでは、新しいオプションとしてユニバーサルパッケージ（UPack）が表示されます（下の画像を参照）。 詳細については、upsteamソースの構成に関するドキュメントをご覧ください。

upsteamソースのユニバーサルパッケージは、同じDevOps organization内のフィード間でのみサポートされていることに注意してください。今後のスプリントサイクルで、AADに関連付けられた他のorganizationのフィードを参照する機能追加を計画しています。

Mavenパッケージを更新するREST APIが一般提供されました

Azure Artifactsの "Update Package Version" REST APIを使用してMavenパッケージのバージョンを更新できるようになりました。以前は、REST APIを使用してNuGet、Maven、npm、Universal Packagesのパッケージのバージョンを更新することができましたが、Mavenパッケージは更新できませんでした。

Mavenパッケージを更新するには、以下のようにHTTP PATCHコマンドを使用します。

PATCH https://pkgs.dev.azure.com/{organization}/{project?}/_apis/packaging/feeds/{feedId}/maven/groups/{groupId}/artifacts/{artifactId}/versions/{packageVersion}?api-version=5.1-preview.1

各パラメーターには以下の値を指定します。

URI Parameters

Name	In	Required	Type	Description
artifactId	path	TRUE	string	パッケージのArtifact ID
feed	path	TRUE	string	feedのNameもしくはID
groupId	path	TRUE	string	パッケージのGroup ID
organization	path	TRUE	string	Azure DevOps organizationの名前
version	path	TRUE	string	パッケージのバージョン
project	path		string	プロジェクトIDかプロジェクト名
api-version	query	TRUE	string	使用するAPIのバージョン。このAPIを使用する場合、'5.1-preview.1'を指定しなければならない

Request Body

Name	Type	Description
views	JsonPatchOperation	追加されるパッケージバージョンのビュー

詳細は、更新されたREST APIのドキュメントをみてください。

Next steps

注意事項

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

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

Go to Azure DevOps Services

Feedback

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

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

Aaron Hallberg