拡張 YAML プレビュー API とユニバーサル パッケージのアップストリーム ソースの構成
このスプリントでは、最終的な YAML 本文を取得できる新しい API エンドポイントをロールアウトします。 また、このリリースでは、ユニバーサル パッケージのアップストリーム ソースを構成する機能が追加されたことをお知らせします。
詳細については、以下の 機能 の一覧を参照してください。
機能
Azure Boards
- バックログとボード上のシステム作業項目の種類
- 監査ログ イベント
- Azure Boards GitHub アプリ リポジトリ制限の発生 (プライベート プレビュー)
- pull request がマージされたときに作業項目の状態をカスタマイズする (プライベート プレビュー)
Azure Pipelines
- パイプライン画像の発表
- エージェント ログのアップロードの改善
- (オプション) コンテナー ボリュームの読み取り専用でのマウント
- コンテナーの開始/停止をきめ細かく制御
- 各ステップのタスク バンドルの解凍
- アクセス トークンのスコープを制限してリリースのセキュリティを強化する
- YAML プレビュー API の機能強化
Azure Artifacts
Azure Boards
バックログとボード上のシステム作業項目の種類
選択したバックログ レベルにシステム作業項目の種類を追加できる機能のプライベート プレビューを開始しました。 これまで、これらの作業項目の種類はクエリからのみ使用できます。
| Process | 作業項目の種類 |
|---|---|
| アジャイル | 問題点 |
| スクラム | 障害 |
| CMMI | 変更要求 |
| 問題点 | |
| 確認 | |
| リスク |
この機能がプレビューから外れ、すべての組織で一般公開されたことをお知らせします。 システム作業項目の種類をバックログ レベルに追加するのは簡単です。 カスタム プロセスに移動し、[バックログ レベル] タブをクリック するだけです。選択したバックログ レベル (例: 要件バックログ) を選択し、 編集オプションを選択します。 次に、作業項目の種類を追加します。
監査ログ イベント
お客様がプロセス関連の変更をより適切に追跡できるように、監査ログに新しいイベントが追加されました。 選択リストの値が変更されるたびに、イベントがログに記録されます。 通常、選択リスト フィールドへの変更は、プロセスに加えられた最も一般的な変更です。 この新しいイベントにより、組織の管理者は、それらのフィールドに変更を加えた日時とユーザーをより適切に追跡できます。
Azure Boards GitHub アプリ リポジトリ制限の発生 (プライベート プレビュー)
GitHub マーケットプレースから Azure Boards アプリケーションを使用している場合、接続できる GitHub リポジトリは 100 個に制限されています。 これは、100 を大幅に超えるリポジトリを持つ大規模な組織にとって阻害要因になります。 このスプリントでは、Azure Boards が GitHub リポジトリに接続して 100 を十分にサポートする方法を変更しました。 現在 100 個のリポジトリの制限に達している場合は、お知らせください。この機能を有効にすると、その制限を引き上げてブロックを解除できます。 組織名 (dev.azure.com/{organization}) を直接メールでお送りください。
pull request がマージされたときに作業項目の状態をカスタマイズする (プライベート プレビュー)
すべてのワークフローが同じであるわけではありません。 一部のお客様は、Pull Request が完了したときに関連する作業項目を閉じたいと考えています。 他のユーザーは、作業項目を閉じる前に検証する別の状態に設定する必要があります。 両方を許可する必要があります。
スプリント 174 以降では、pull request のマージと完了時に作業項目を目的の状態に設定できる新機能が追加されました。 これを行うには、pull request の説明をスキャンし、状態の値の後に作業項目の #メンションを探します。 この例では、2 つのユーザー ストーリーを [解決済み] に設定し、2 つのタスクを閉じています。
この機能は長い時間が経過しており、お客様のご検討に興奮しています。 まず、プル要求の説明をスキャンするだけで、ユーザー インターフェイスの変更は含まれません。 さらに投資する前に、まずフィードバックをお寄せください。
プライベート プレビュー への参加に関心がある場合は、直接メールでお問い合わせください。 組織 (dev.azure.com/{organization}) を忘れないでください。
Azure Pipelines
パイプライン画像の発表
Note
Azure Pipelines イメージは、ユーザーに可能な限り最高のエクスペリエンスを提供するために継続的に更新されます。 これらの定期的な更新は、主にバグや古いソフトウェアに対処することを目的としています。 多くの場合、パイプラインには影響しませんが、必ずしもそうであるとは限りません。 パイプラインが、イメージで削除または更新されたソフトウェアの一部に依存する場合、影響を受ける可能性があります。
Windows、Linux、macOS イメージの今後の更新プログラムの詳細については、次のお知らせをお読みください。
今後 (プレリリース) およびデプロイされた変更のリリース ノートを表示するには、次のリリース ノートをサブスクライブしてください。
エージェント ログのアップロードの改善
エージェントが Azure Pipelines サーバーとの通信を停止すると、実行されていたジョブは破棄されます。 ストリーミング コンソールのログを見ていた場合は、エージェントが応答を停止する直前に、エージェントの状態に関するいくつかの手掛かりを得ている可能性があります。 しかし、そうでない場合、またはページを更新した場合、それらのコンソール ログは失われました。 このリリースでは、エージェントが完全なログを送信する前に応答を停止した場合は、コンソール ログを次に最適なものとして保持します。 コンソール ログは 1 行あたり 1,000 文字に制限されており、不完全な場合もありますが、何も表示しないよりもはるかに便利です。 これらのログを調べることは、独自のパイプラインのトラブルシューティングに役立つ場合があり、サポート エンジニアがトラブルシューティングを支援する際に役立ちます。
(オプション) コンテナー ボリュームの読み取り専用でのマウント
Azure Pipelines でコンテナー ジョブを実行すると、ワークスペース、タスク、およびその他のマテリアルを含む複数のボリュームがボリュームとしてマップされます。 これらのボリュームは、既定で読み取り/書き込みアクセスに使用されます。 セキュリティを強化するために、YAML でコンテナーの仕様を変更することで、ボリュームを読み取り専用でマウントできます。 下の mountReadOnly 各キーは読み取り専用に true 設定できます (既定値は false)。
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 にマッピングする文字列化された JSON オブジェクトが含まれています。
各ステップのタスク バンドルの解凍
エージェントは、ジョブを実行するときに、ジョブのステップで必要なすべてのタスク バンドルを最初にダウンロードします。 通常、パフォーマンスのために、タスクが複数のステップで使用されている場合でも、ジョブごとに 1 回タスクを解凍します。 解凍されたコンテンツを変更する信頼されていないコードに関する懸念がある場合は、エージェントが各使用法でタスクを解凍することで、少しのパフォーマンスを低下させることができます。 このモードを有効にするには、エージェントを構成するときに渡します --alwaysextracttask 。
アクセス トークンのスコープを制限してリリースのセキュリティを強化する
Azure Pipelines のセキュリティ設定を強化する取り組みに基づいて、リリースのアクセス トークンのスコープの制限がサポートされるようになりました。
リリースで実行されるすべてのジョブは、アクセス トークンを取得します。 アクセス トークンは、タスクとスクリプトによって使用され、Azure DevOps にコールバックされます。 たとえば、アクセス トークンを使用して、ソース コードの取得、成果物のダウンロード、ログのアップロード、結果のテスト、または Azure DevOps への REST 呼び出しを行います。 ジョブごとに新しいアクセス トークンが生成され、ジョブが完了すると有効期限が切れます。
この更新プログラムでは、アクセス トークンのスコープを制限し、従来のリリースに拡張することで、パイプラインのセキュリティを強化することに基づいて 構築されています 。
この機能は、新しいプロジェクトや組織に対して既定でオンになります。 既存の組織の場合は、Organization 設定 Pipelines > 設定>で有効にする必要があります。 >リリース パイプラインのジョブ承認スコープを現在のプロジェクトに制限します。 こちらをご覧ください。
YAML プレビュー API の機能強化
いくつかのスプリントでは、パイプラインの完全な YAML を実行せずにプレビューする機能が導入されました。 この更新プログラムでは、プレビュー機能用の専用の新しい URL が作成されました。 POST を実行して https://dev.azure.com/{org}/{project}/_apis/pipelines/{pipelineId}/preview 、完成した YAML 本文を取得できるようになりました。 この新しい API は、実行をキューに登録するのと同じパラメーターを受け取りますが、"キュー ビルド" アクセス許可は必要なくなりました。
Azure Artifacts
ユニバーサル パッケージの上流ソースの構成
これで、必要に応じてアップストリーム ソースからユニバーサル パッケージを自動的にダウンロードするように Azure Artifacts フィードを構成できます。
以前は、NuGet、Python、Maven、および npm パッケージのフィードでアップストリーム ソースを構成できましたが、ユニバーサル パッケージには構成できませんでした。 これは、ユニバーサル パッケージに使用されるストレージ テクノロジの違いによるものです。これは、サポートされている他のパッケージの種類よりもはるかに大きなパッケージをサポートしています。
ユニバーサル パッケージのアップストリーム ソースは、他のパッケージの種類と同じ方法で構成できるようになりました。フィード設定を開き、[アップストリーム ソースの追加>] を>クリックし、適切なソースの種類を選択します。 次のビューには、新しいオプションとしてユニバーサル パッケージ (UPack) が表示されます (下の画像を参照)。 詳細については、アップストリーム ソースの構成 ドキュメントを参照してください。
アップストリーム ソースのユニバーサル パッケージは、同じ DevOps 組織のフィード間でのみサポートされることに注意してください。
更新プログラム パッケージのバージョン REST API を Maven パッケージで使用可能に
Azure Artifacts の "パッケージ バージョンの更新" REST API を使用して、Maven パッケージのバージョンを更新できるようになりました。 以前は、REST API を使用して、NuGet、Maven、npm、およびユニバーサル パッケージのパッケージ バージョンを更新できましたが、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 パラメーター
| 名前 | In | 必須 | Type | 説明 |
|---|---|---|---|---|
| artifactId | path | TRUE | string | パッケージの成果物 ID |
| feed | path | TRUE | string | フィードの名前または ID |
| groupId | path | TRUE | string | パッケージのグループ ID |
| 組織 | path | TRUE | string | Azure DevOps 組織の名前 |
| version | path | TRUE | string | パッケージのバージョン |
| project | path | string | プロジェクト ID またはプロジェクト名 | |
| api-version | query | TRUE | string | 使う API のバージョン。 このバージョンの API を使用するには、これを '5.1-preview.1' に設定する必要があります |
要求本文
| 名前 | タイプ | 説明 |
|---|---|---|
| ビュー | JsonPatchOperation | パッケージ のバージョンが追加されるビュー |
詳細については、更新される REST API のドキュメント を参照してください。
次のステップ
Note
これらの機能は、今後 2 ~ 3 週間にわたってロールアウトされます。
Azure DevOps に向かい、見てみましょう。
フィードバックの提供方法
これらの機能に関するご意見をお聞かせください。 ヘルプ メニューを使用して、問題を報告したり、提案を提供したりします。
Stack Overflow のコミュニティからアドバイスや質問に回答してもらうこともできます。
よろしくお願いします。
アーロン・ハルベルク
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示