次の方法で共有

新しい Boards Hubs パブリック プレビュー

  • [アーティクル]

新しい Boards Hubs がパブリック プレビューで利用できるようになりました。 Web プラットフォームが更新され、新しいモダン デザイン、応答性の高いリフロー、アクセシビリティコンプライアンス、ページパフォーマンスの向上が実現しました。

詳細については、リリース ノートを参照してください。

全般

Azure Boards

Azure Pipelines

全般

監査は、organizationのオプトイン機能になりました

監査は、Azure DevOps でオプトイン機能になりました。 現在、organizationが監査をアクティブに使用していない場合 (つまり、過去 90 日間に少なくとも 2 回監査ログにアクセスしたか、監査ストリームが構成されている場合)、organizationの監査機能を明示的にオンにして監査を開始する必要があります。 オンにすると、監査イベントがorganizationの監査ログに含まれます。 監査のアクティブなユーザーである組織の場合、この機能は [オン] のままです。

[組織の設定] ページから、organizationで監査を有効にすることができます。

右側のサイドバーには、[セキュリティ] ヘッダーの下に [ポリシー] が表示されます。 organizationが Azure Active Directory によってサポートされていると仮定すると、有効にできるセキュリティ ポリシーの 1 つがログ監査イベントであることがわかります。 MSA が支援する組織では、監査機能は使用できなくなります。

イベントを監査する

このポリシー を [オン] と [ 監査] に切り替えるだけです (すぐに表示されない場合は、ページを更新し、使用可能にする必要があります)。 監査イベントを受信しない場合は、ボタンを [オフ] に切り替えます。 ボタンをオフにすると、サイドバーに [監査] ページが表示されなくなり、[監査ログ] ページは使用できなくなります。 構成されているすべての監査ストリームは、イベントの受信を停止します。

ゲスト ユーザーにはパブリック ユーザー データのみが表示されます

外部ゲスト アクセス ポリシーが無効で、[パブリック プロジェクトを許可する] ポリシーが有効になっている場合、ゲスト ユーザーは、パブリック プロジェクトのメンバーの表示名などのパブリック ユーザー データのみを表示できます。 これは、匿名ユーザーに付与されるのと同じエクスペリエンスです。 これは、Web エクスペリエンスを通じて利用できる個人データ (ユーザーが別のユーザーをメンションしようとしたり作業項目を割り当てたりしたときに表示される ID ピッカーなど) と、REST API を通じて利用できる個人データに適用されます。

Azure Boards

新しい Boards Hubs がパブリック プレビューで利用可能になりました

この数か月間、チームは Azure Boards Hubs のユーザー エクスペリエンスの最新化に重点を置いてきました。 UI が更新され、より高速なユーザー インターフェイス、製品の他の部分との一貫性、およびアクセシビリティが向上しました。 チームは、新しいAzure Boardsエクスペリエンスのパブリック プレビューを最終的に発表することに興奮しています。

機能は変わりませんが、次のことが期待できます。

  • モダン デザイン
  • レスポンシブ リフロー
  • パフォーマンスの向上
  • アクセシビリティコンプライアンス

パブリック プレビューにオプトインするには、[プレビュー機能] セクションで、 New Boards Hubs という名前の機能を [オン] に切り替えます。

Gif を使用してパブリック プレビューへのオプトインをデモします。

何らかの理由で 新しいボード ハブ によってブロックの問題が発生している場合は、プレビューをオフにすることができます。 しかし、新しいエクスペリエンスをお試しいただき、 フィードバックをお寄せください。 不足している、または期待どおりに動作していない場合は、必ずお知らせください。

Azure Pipelines

拡張 YAML パイプライン テンプレートに、ステージ、ジョブ、デプロイのコンテキスト情報を渡すようになりました

この更新プログラムでは、テンプレートと組み合わせて使用することを目的とした、、deployment、および stage YAML パイプライン コンポーネントの新しいtemplateContextプロパティjobを追加します。

を使用 templateContextするシナリオを次に示します。

  • テンプレートを使用して、コードの重複を減らすか、 パイプラインのセキュリティを向上させます

  • テンプレートは、、、または のstagesjobs一覧をパラメーターとして受け取りますdeployments

  • テンプレートは入力リストを処理し、各ステージ、ジョブ、またはデプロイに対していくつかの変換を実行します。 たとえば、各ジョブを実行する環境を設定したり、コンプライアンスを適用するための追加の手順を追加したりします。

  • この処理では、パイプライン作成者がリスト内のステージ、ジョブ、またはデプロイごとにテンプレートに追加の情報を渡す必要があります

例を見てみましょう。 たとえば、pull request 検証のためにエンドツーエンドのテストを実行するパイプラインを作成しているとします。 目標は、システムの 1 つのコンポーネントのみをテストすることですが、エンドツーエンドのテストを実行する予定であるため、システムのコンポーネントの多くを使用できる環境が必要であり、それらの動作を指定する必要があります。

他のチームにも同様のニーズがあることに気付いているので、環境をテンプレートに設定するための手順を抽出することにしました。 そのコードは次のようになります。

testing-template.yml

parameters: 
- name: testSet
  type: jobList

jobs:
- ${{ each testJob in parameters.testSet }}:
  - ${{ if eq(testJob.templateContext.expectedHTTPResponseCode, 200) }}:
    - job:
      steps:
        - script: ./createSuccessfulEnvironment.sh ${{ testJob.templateContext.requiredComponents }}
        - ${{ testJob.steps }}
  - ${{ if eq(testJob.templateContext.expectedHTTPResponseCode, 500) }}:
    - job:
      steps:
        - script: ./createRuntimeErrorEnvironment.sh ${{ testJob.templateContext.requiredComponents }}
        - ${{ testJob.steps }}

テンプレートの実行内容は、 パラメーター内の各ジョブについて testSet 、${{ testJob.templateContext.requiredComponents }} で指定されたシステムのコンポーネントの応答を設定して${{ testJob.templateContext.expectedHTTPResponseCode }} を返します。

その後、次の例のように拡張 testing-template.yml する独自のパイプラインを作成できます。

sizeapi.pr_validation.yml

trigger: none

pool:
  vmImage: ubuntu-latest

extends:
  template: testing-template.yml
  parameters:
    testSet:
    - job: positive_test
      templateContext:
        expectedHTTPResponseCode: 200
        requiredComponents: dimensionsapi
      steps:
      - script: ./runPositiveTest.sh
    - job: negative_test
      templateContext:
        expectedHTTPResponseCode: 500
        requiredComponents: dimensionsapi
      steps:
      - script: ./runNegativeTest.sh

このパイプラインは、正と負の 2 つのテストを実行します。 どちらのテストでも、コンポーネントを dimensionsapi 使用できる必要があります。 ジョブは positive_test HTTP コード 200 を dimensionsapi 返しますが、 negative_test HTTP コード 500 を返す必要があります。

Windows 2016 ホストイメージの廃止日を更新しました

Windows 2016 イメージの提供終了日を 4 月 1 日から 6 月 30 日に変更しました。 このイメージを使用しているほとんどのお客様はパイプラインを更新していますが、このイメージを使用しているお客様はまだいます。 organizationが Windows 2016 を使用しているかどうかを確認するには、次の手順を使用して、非推奨のイメージを使用してパイプラインを識別します。

お客様がパイプラインを特定できるように、引き続きブラウンアウトを実行します。 これらは、イメージが使用できない 24 時間の期間であり、この期間中に実行されるパイプライン ジョブが失敗します。 ブラウンアウトは次の場合に発生します。

  • 4 月 18 日 (月)
  • 火曜日 4 月 26 日
  • 5 月 4 日 (水)
  • 5 月 12 日木曜日
  • 金曜日 5 月 20 日
  • 5 月 23 日 (月)
  • 火曜日 5 月 31 日
  • 6 月 8 日 (水)
  • 6 月 16 日木曜日
  • 金曜日 6 月 24 日
  • 6 月 27 日 (月)

次の手順

Note

これらの機能は、今後 2 ~ 3 週間にわたってロールアウトされます。

Azure DevOps に向かい、見てみましょう。

Azure DevOps に移動する

フィードバックの提供方法

これらの機能に関するご意見をお聞かせください。 ヘルプ メニューを使用して、問題を報告したり、提案を提供したりします。

ご提案の送信

Stack Overflow のコミュニティが回答したアドバイスや質問を受けることもできます。

よろしくお願いします。

アーロン・ハルベルク