Azure DevOpsのSprint 143 Updateでは、より強力で使いやすい新しい作業項目エディターを紹介しています。これは、製品全体のエクスペリエンスをモダナイズする、当社の取り組みの一環です。Azure Reposでは、pull requestの下書きを使用してpull requestが作成できます。下書き状態のpull requestはまだ完了していないため、誤って完了することはありません。Azure Artifactsでは成果物からファイルを除外してアップロードできるようになり、パッケージ出所の情報をわかりやすくする機能といった、いくつかの新機能もリリースしています。
以下のリストで紹介する機能を是非体験してください。
General:
Azure Boards:
Azure Repos:
Azure Pipelines:
- YAMLパイプラインを起動するタグを指定する
- pull request更新時、既存のパイプラインを自動的にキャンセルする
- コンテナーリソースのインライン宣言
- 新しいプロジェクトで既定の権限を変更
- Deployment Groupeで失敗したターゲットへのデプロイ
- 失敗時自動的に再デプロイする
- Infrastructure as Codeのサポート
Azure Artifacts:
Reporting:
すべてのAPIリクエストには、api-versionが含まれている必要があります。ただし、以前にapi-versionなしでリリースされたエンドポイントに対してRESTリクエストを行う場合、このデプロイメントでは、そのリクエストのデフォルトバージョンが4.1から5.0に切り替わります。RESTおよびAPIバージョンの詳細については、Azure DevOps Services REST APIリファレンスを参照してください。
作業項目フォーム用の新しいテキストエディターの一般提供が開始されたことをお知らせします。当社のテキストエディターはしばらく改善されていないため、古くなっていましたが、今回の強化で提供されるエディターにより、エクスペリエンスは大幅に改善されます。新しいエディターは、イメージのサイズ変更、コードスニペット、MacとWindowsの両方のキーボードショートカット、完全な絵文字ライブラリなどの新しい機能をもたらし、よりモダンで強力です。
このコントロールは、ディスカッションにも含まれ、作業項目フォームの任意のテキストフィールドで使用できます。こちらで新しいエクスペリエンスを紹介します。
以下で、コードスニペットの操作を確認できます。この追加により、作業項目フォームでコードを簡単かつ明確に議論できるようになります。
我々は実際に作業項目をよりソーシャルなエクスペリエンスとして提供したいと考えています。その道のりの第一歩として、テキストフィールドに絵文字をサポートし、作業項目について議論することです。emojiを使用すると、あなたの説明やコメントを生き生きとさせられるので、もう少し個性を表現できます！
このエディターはオープンソースとして開発しているので、GitHubのhttps://github.com/Microsoft/roosterjsにあるroosterjsレポでチェックしてください。
Azure Reposにおけるエクスペリエンスのほとんどは、レポを選択して、ブランチを選択する操作が大部分です。多数のブランチを持つ組織で、このエクスペリエンスを向上させるため、新しいブランチピッカーを展開しています。ピッカーで、好きなブランチを選択したり、ブランチをすばやく検索したりできます。
pull requestで作業する場合、全員の作業が完了するまでpull requestが完了しないようにする進行中のpull requestを簡単に作成できるようにするため、pull requestの下書き機能をサポートします。
pull requestの下書きは、pull requestを作成するとき、CreateボタンのドロップダウンからCreate as draftを選択すると作成できます。
pull requestの下書きを作成すると、そのタイトルの横にステータスを示すバッジが表示されます。
下書き状態のpull requestには、レビュー担当者が含まれていないか、デフォルトでビルドが実行されていませんが、レビュー担当者を手動で追加してビルドを実行できます。pull requestを通常のプルリクエストに昇格させるには、pull requestの詳細ページからPublishボタンをクリックします。
タグがcommitに追加されると、YAMLパイプラインが起動されます。これは、tagを使ったワークフローを運用しているチームにとって有益です。たとえば、commitに「最後に成功した」とタグ付けされたときに、プロセスを開始できます。
含めるタグと除外するタグを指定できます。 たとえば：
trigger:
tags:
include:
- releases/*
exclude:
- releases/old*既定では、新しいコミットが同じPRにプッシュされると、pull request(PR)によって起動されたパイプラインはキャンセルされます。これは、通常、古いコードでパイプラインを実行し続けるケースはあまりないため、ほとんどの場合に適しています。しかし、パイプラインを継続実行し続けたい場合は、autoCancel:falseをPRトリガーに追加してください。
pr:
branches:
include:
- master
- releases/*
autoCancel: false前のバージョンまでは、コンテナリソースをYAMLパイプラインで宣言し、名前で参照する必要がありました。コンテナーを複数回参照しなくてもいい場合のインライン構文を提供します。
jobs:
- job: my-container-job
container:
image: microsoft/dotnet:latestこれまでは、Create build definition(訳注:ビルド定義の作成)権限が明示的に与えられていない限り、プロジェクトのContributer(訳注:コードの編集権限がある人)はパイプラインを作成できませんでした。新しいプロジェクトでは、すべてのチームメンバーがパイプラインを簡単に作成および更新できます。今回の強化により、Azure Pipelinesに取り組む新規顧客との摩擦が軽減されます。いつでもContributorsグループのデフォルトのアクセス権を更新すると、ビルド定義へのアクセスを制限できます。
既定では、失敗した実行を再デプロイしたときにAzure Pipelinesはすべてのジョブを再実行していました。今回の強化で、展開時にDeployment Optionを構成すると、この動作を無効にできます。All jobs and limit to failed targets in a deployment group(訳注:すべてのジョブとデプロイメント・グループ内の失敗したターゲットへの制限)オプションを選択すると、再実行によってすべてのジョブが実行され、すでにデプロイされているターゲットにデプロイメントがスキップされます。
ステージへのデプロイが失敗した場合、Azure Pipelinesは最後の正常なデプロイメントを自動的に再デプロイできるようになりました。 Post-deployment conditions(訳注:デプロイ後の条件)でAuto-redeploy trigger(訳注:自動再デプロイメントトリガー)を設定すると、ステージへ最後の正常なリリースを自動的いデプロイするように設定できます。将来のスプリントでは自動再デプロイメント構成にトリガーが構成されたイベントとアクションを追加する予定です。詳細については、Deployment groupsのドキュメントを参照してください。
私たちはAzure DevOpsプロジェクトにInfrastructure as Code(IaC)のサポートを追加しています。IaCは、伝統的なインタラクティブな設定ツールの代わりに、定義ファイルを使用して設定を行いながら、宣言的なアプローチでコンピューティングインフラストラクチャを管理およびプロビジョニングするプロセスです。今回の強化で、ソリューション内のリソースをグループとして扱えるようになりました。展開用のテンプレートを使用して、ソリューションのすべてのリソースを展開、更新、または削除できます。このテンプレートは、テスト、ステージング、およびプロダクションなどのさまざまな環境で使用できます。
今までは公開された成果物からファイルを除外するには、ファイルをステージングディレクトリにコピーし、除外するファイルを削除してからアップロードする必要がありました。今回の強化で、Universal PackagesとPipeline成果物の両方が、アップロードディレクトリにある.artifactignoreというファイルを探して、それらのファイルを自動的に除外し、ステージングディレクトリの必要性を排除します。
今回のアップデートでは、パッケージの発行元や発行元、ソースコードの由来など、パッケージの出所を少し簡単に理解できるようになりました。この情報は、Azure PipelinesのNuGet、npm、およびMavenタスクを使用して公開されたすべてのパッケージに対して自動的に入力されます。
このスプリントの更新では、Azure Artifacts REST APIのドキュメントを大幅に更新しています。これにより、自分のアプリケーションで簡単に開発できるようになります。
Azure DevOps組織にAnalytics ExtensionをインストールしたユーザーがTest result trend widgetを利用できるようになりました。複数のビルドおよびリリースのテストデータをほぼリアルタイムで可視化できます。Test results trend widgetは、パイプラインのテスト結果のトレンドを表示します。 このウィジェットを使用するとテスト、合格率およびテスト期間の日別数の追跡ができます。健全なDevOpsパイプラインを維持するためには、時間の経過とともにテスト品質が下がらないように追跡しつづける点が重要です。
Test result trend widgetを使用すると、テスト結果の異常値を見つけたり、通常よりもテストを実行する時間が長くかかったり、マイクロサービスが合格率に影響を与えているかといった疑問に対する答えを与えてくれます。これらの疑問への答えを見つけるために、ウィジェットは次の機能を提供します。
- テスト間隔での通過率のトレンド、テスト結果の数を表示する。
- 複数のビルドおよびリリースパイプラインに基づいたテスト結果を表示する。
- 結合されたチャートオプションを使用して、同じトレンドで2つの指標を表示する。
- テスト結果によって時間をかけてテストカウントをフィルタリングする。
- ブランチまたはテストですべてのテスト結果をフィルターする。
- PriorityまたはEnvironmentなどのテスト属性で統計情報をスタックします。
このウィジェットは高度な設定が可能であるため、さまざまなシナリオに適しています。
注意事項
ここで議論されている機能は今後二～三週にわたって順次展開されます。
これらの新機能を読んだ後、次のリンクからぜひご自身でAzure DevOpsサービスを体験してみてください。
これらの機能についてどう思っているかお聞きしたいと思います。 フィードバックメニューを使用して問題を報告するか、提案を提出してください。
アドバイスや回答を必要とする質問がある場合、Stack Overflowコミュニティで聞いてください。
ありがとうございました。
Jeremy Epling