新しいBoards Hubsのパブリックプレビューを開始しました。ウェブプラットフォームが更新され、新しいモダンなデザイン、レスポンシブなリフロー、アクセシビリティへの対応、ページパフォーマンスの向上が実現されました。
詳しくは、リリースノートをご覧ください。
- organiztionの監査機能がオプトインに変更されます
- IPアドレスベースの条件付きアクセスポリシーを設定している場合にログインループが発生していた状況を修正しました
- ゲストユーザーは公開されているユーザーデータのみ参照可能になります
- YAMLパイプラインテンプレートを拡張して、stage, job, deploymentでコンテキストの流用ができるようになりました
- Windows 2016 hosted imagesリタイア日程を更新しました
Azure DevOpsでは、監査がオプトイン機能になりました。現在、組織が監査を積極的に使用していない場合（過去90日間に少なくとも2回監査ログにアクセスした、または構成された監査ストリームがあるなど）、組織が監査を開始するには、監査機能を明示的にOnにする必要があります。Onにした後、監査イベントは組織の監査ログに含まれます。監査機能のアクティブユーザーである組織の場合、この機能はオンのままです。
組織の監査は、Organization settingsから有効にできます。
右側のサイドバーで、Security ヘッダーの下にPoliciesが表示されます。組織がAzure Active Directoryアカウントで運用されている場合、有効にするセキュリティポリシーのひとつにLog Audit Eventsがあることが確認できるはずです。MSA（訳注：個人用Microsoftアカウントのこと）で運用されているorganiztionでは、監査機能は使用できなくなります。
このポリシーをOnに切り替えるだけで、監査が利用できるようになります（すぐに表示されない場合は、ページを更新すると利用できるようになります）。監査イベントを受け取りたくない場合は、このボタンをオフに切り替えてください。ボタンをOffに切り替えると、サイドバーにAuditingページが表示されなくなり、Auditingページも使用できなくなります。設定されているすべての監査ストリームは、イベントの受信を停止します。
Azure DevOpsにログインしようとするとループする問題が一部のユーザーで報告されていましたが、修正しました。
この問題は、IPv4の範囲のみを受け入れるように条件付きアクセスポリシーを構成したテナントに属するユーザー、またはIPv6アドレスを誤ってブロックしたユーザーに対して発生していました。このループの問題は解決され、影響を受けるユーザーには、IPに対して設定された条件付きアクセス ポリシー (CAP) のチェックに失敗したことを説明するエラーメッセージが表示されるようになりました。推奨される対処法は、ユーザーがAAD管理者に頼んで、自分のIPv6アドレスが許可リストに含まれていることを確認することです。
IPv6が許可リストに含まれているにもかかわらずログインに問題がある場合、ユーザーがAzure Active Directoryログインページ (login.microsoftonline.com)にAzure DevOps(dev.azure.com)の残りの部分へのアクセスに使用しているものとは異なるIPアドレスからアクセスしている可能性があることが判明しています。IPベースのCAPチェックでは、「Azure Active Directory条件付きアクセス ポリシーの検証を有効にする」ポリシーが無効になっている場合でも、Azure Active Directoryログインポータル(login.microsoftonline.com)の両方のIPアドレスで常にチェックが行われます。
Azure DevOpsへのアクセスに使用しているVPN設定やネットワークインフラストラクチャを確認し、マシンのすべてのIPアドレスがCAP許可リストに含まれていることを確認することをお勧めします。さらに問題がある場合は、サポートに連絡してください。
External guest accessをdisabledにし、Allow public projectsの許可ポリシーをenabledにすると、ゲストユーザーは公開プロジェクトのメンバーの表示名などの公開ユーザーデータのみを参照できるようになります。これは、匿名ユーザーに対して付与されるのと同じエクスペリエンスです。これは、Webエクスペリエンスを通じて利用できる個人データ（ユーザーが他のユーザーに言及したり、ワークアイテムを割り当てようとしたときに表示されるアイデンティティピッカーなど）および当社のREST APIを通じて利用できる個人データにも当てはまります。
ここ数ヶ月、私たちのチームはAzure Boards Hubsのユーザーエクスペリエンスをモダナイズすることに注力してきました。UIはより高速なユーザーインターフェイス、製品の他の部分との一貫性、およびアクセシビリティの向上を提供するために更新されました。チームは新しいAzure Boardsエクスペリエンスのパブリック プレビューをついに発表できることに興奮しています。
機能は変わりませんが、以下のような改善が期待されています。
- モダンなデザイン
- レスポンシブ・リフロー
- パフォーマンスの向上
- アクセシビリティへの対応
パブリックプレビューに参加するには、プレビュー機能セクションでNew Boards Hubsという機能をOnに切り替えてください。
何らかの理由でNew Boards Hubsが原因でブロッキングとなる問題を引き起こしている場合、プレビューをオフにできます。しかし、新しいエクスペリエンスを試してみて、フィードバックを送ってください。何か不足しているものや期待通りに動作しないものがあれば、必ずお知らせください。
今回の更新では、テンプレートと組み合わせて使用されるjob、deployment、stageのYAMLパイプラインコンポーネントに、新しいtemplateContextプロパティを追加します。
ここでは、templateContextを使用するためのシナリオを説明します。
- コードの重複を減らすため、またはパイプラインのセキュリティを向上させるためにテンプレートを使用します。
- テンプレートは
stage、job、またはdeploymentにおいて、入力リストをパラメータとして受け取ります。 - テンプレートは入力リストを処理し、stage、job、またはdeploymentのそれぞれに対していくつかの変換を実行します。たとえば、各ジョブが実行される環境を設定したり、コンプライアンスを強化するために追加のステップを追加したりします。
- この処理では、パイプライン作成者がリスト内の各ステージ、ジョブ、またはデプロイメントのテンプレートに渡す追加情報が必要です。
例を見てみましょう。プルリクエストの検証のために、エンドツーエンドのテストを実行するパイプラインを作成するとします。しかし、エンドツーエンドテストを実行する予定なので、システムの多くのコンポーネントが利用できる環境が必要であり、その挙動を指定する必要があります。
他のチームも同じようなニーズを持っていることがわかったので、環境をセットアップするための手順をテンプレートに抽出することにしました。そのコードは次のようなものです。
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ジョブはdimensionsapiがHTTPコード200を返すことを期待し、negative_testは HTTP コード 500 を返すことを期待します。
Windows 2016 イメージのリタイア日を4月1日から6月30日に変更しました。このイメージを使用しているほとんどのお客様はパイプラインを更新していますが、まだこのイメージを使用しているお客様もいらっしゃいます。お客様の組織がWindows 2016を使用しているかどうかを確認するには、以下の手順を使用して、非推奨のイメージを使用しているパイプラインを特定します。
お客様がパイプラインを特定できるようにするため、引き続きブラウンアウトを実施する予定です。これは、イメージが利用できなくなる24時間の期間であり、この間に実行されるパイプラインのジョブが失敗する原因となります。ブラウンアウトは以下の日に行われます（訳注：おそらくUTC）。
- 4/18 月曜
- 4/26 火曜
- 5/4 水曜
- 5/12 木曜
- 5/20 金曜
- 5/23 月曜
- 5/31 火曜
- 6/8 水曜
- 6/16 木曜
- 6/24 金曜
- 6/27 月曜
注意事項
ここで議論されている機能は今後二～三週にわたって順次展開されます。
これらの新機能を読んだ後、次のリンクからぜひご自身でAzure DevOpsサービスを体験してみてください。
これらの機能についてどう思っているかお聞きしたいと思います。 フィードバックメニューを使用して問題を報告するか、提案を提出してください。
アドバイスや回答を必要とする質問がある場合、Stack Overflowコミュニティで聞いてください。
ありがとうございました。
Aaron Hallberg