Instantly share code, notes, and snippets.

Embed
What would you like to do?
Translate to Japanese to Azure DevOps release notes from https://docs.microsoft.com/en-us/azure/devops/release-notes/2018/sprint-142-update

Azure PipelinesにおけるYAMLの強化 - Sprint 142の更新

Azure DevOpsのSprint 142 Updateでは、ビルドにカスタムカウンタを追加するプルリクエスト用にビルドするブランチを指定するテンプレートをインラインで使用するなど、YAMLのいくつかの改良が行われました。また、すべてのユーザーのために新しいナビゲーションを有効にしダークテーマを導入し、Azure Boardのリンク添付ファイルのエクスペリエンスを向上させました。

以下のリストで紹介する機能を是非体験してください。

Features

General:

Azure Boards:

Azure Repos:

Azure Pipelines:

Azure Test Plans:

Azure Artifacts:

Wiki:

Administration:

General

すべてのユーザーに新しいナビゲーションUIを提供

すべてのユーザーのために新しいナビゲーションを有効にしました!これは、当社の新しい製品設計を展開する際の大きなマイルストーンです。このリリースでは、すべてのユーザーを新しいナビゲーションモデルに移行していますが、ユーザーは2019年1月16日まではオプトアウトすることで、古いナビゲーションを継続して使用できます。トップの右上ににあるアバターの下にあるメニューからPreview featuresで選択してください。

詳細については、Navigation Updateのブログ記事を参照してください。

ダークテーマの提供

私たちにとってダークテーマは長年提供したい機能の1つでした。今回新しいナビゲーションの一環として利用できるようになりましたことをお知らせいたします。すべてのページの右上にある、あなたのアバターの下にあるメニューからThemeを選択すると、ダークテーマを有効にできます。

Dark Theme

Azure Boards

作業項目への資料の添付をよりリッチにして集中管理する

作業項目にファイルを添付することで、あなたとあなたのチームは参照資料を集中管理し、必要なときにいつでも手元に持ってこれます。新しい添付ファイル追加は、作業項目フォームのどこにでもファイルをドラッグアンドドロップするだけという、非常に簡単な方法になりました。添付ファイルを一覧表示し続けたり、グリッド表示に切り替えてサムネイルプレビューを表示したりできます。ファイルをダブルクリックすると、プレビューが開き、必要な情報をすばやく見つけられます。

Work item attachments

組織(訳注:Azure DevOpsアカウントのこと)をまたいで作業項目をリンクして、依存関係を管理する

関連する仕事や依存する仕事をリンクすると、あなたが追跡している仕事に幅広いコンテキストを与え、他のチームとの依存関係を管理するために役立ちます。リモート作業のためのリンクにより、社内の組織間の作業を追跡できます。既存の作業項目のURLをコピーして、別の作業項目に移動し、次の3つの新しいリンクタイプのいずれかを使用してリンクを作成するだけです:Consumes From、Produces For、Remote Related。Azure Boardのトレーサビリティの詳細については、作業項目リンクのドキュメントを参照してください。

注意事項

両方のAzure DevOps組織の権限が尊重されます。どちらの組織も同じAzure ADテナントで実行されている必要があります。

Remote link

多くの依存関係を管理し始めると、Queriesの新しいRemote Link Countフィールドを使用して、プロジェクトにリモート依存関係のある作業項目を一覧表示するか、Dependency Tracker機能拡張機能をインストールすることを検討してください。MicrosoftのWindowsグループがスケールニーズを満たすために作成したこの拡張機能は、リモートリンクを基にして、豊富な階層と依存関係のグラフ表示を表示します。

検索結果から作業項目を開く

以前は、作業項目のプレビューペインがオフになっていると、検索結果ページから作業項目を開くことができませんでした。これにより、検索結果を掘り起こすのが難しくなります。今回の強化により、作業項目のタイトルをクリックして、モーダルウィンドウで作業項目を開くことができます。この機能は、UserVoiceの投票に基づいて優先順位が付けられました。

Azure Repos

拡張機能の作者が現在のレポについてコンテキストのクエリを実行可能に

バージョンコントロール拡張の作成者にとっての課題の1つは、名前、ID、URLなど、リポジトリのコンテキストをユーザーに表示することです。これを支援するために、VersionControlRepositoryServiceを拡張アクセス可能サービスとして追加しました。拡張機能の作成者はこれを使用して、Web UI内の現在のGitリポジトリコンテキストに関する情報を問い合わせられるようになりました。現在、getCurrentGitRepository()というメソッドを提供しています。

Gitリポジトリが選択されている場合、リポジトリに関する基本データ(名前、ID、およびURL)とともにGitRepositoryオブジェクトが返されます。TFVCリポジトリが選択されている場合、またはサービスがAzure Reposページの外部にアクセスされている場合は、nullが返されます。このサービスを使用する拡張機能のサンプルを用意しています。

Azure Pipelines

あなたのビルドにカスタムのビルドコンテナーを追加する

ビルドカウンターを使えばビルドに固有の番号とラベルを付ける方法を提供します。以前は$(rev:r)という特別な変数が使えました。今回の強化で、ビルド定義をビルドするたびに自動的にインクリメントされる独自のカウンター変数を定義できます。これは、定義の変数タブで行います。この新機能により、次のような方法でより多くのパワーが得られます。

  • カスタムカウンターを定義し、そのシード値を設定できます。たとえば、100でカウンターを始められます。$(rev:r)は常に0から始まります。
  • 独自のカスタムロジックを使用してカウンターをリセットできます。$(rev:r)はビルド番号の生成に関連付けられており、ビルド番号に新しいプレフィックスがある場合は常に自動リセットされます。
  • 定義ごとに複数のカウンターを定義できます。
  • ビルド外のカウンターの値を問い合わせられます。たとえば、カウンターを使用して最後にリセットした後、実行されたビルドの数を数えられます。

ビルドカウンターの詳細については、User-defined variablesに関する資料を参照してください。

YAMLを使って、pull request向けの特定のブランチのビルドする

YAMLパイプラインでは、PR用に構築するブランチを指定できます(pull request)。含めるブランチと除外するブランチを選択できます。 この機能は以前Web UIで利用できました。YAMLファイルに移動することで、コードとしてのconfig-as-workflowの一部になります。

PRトリガーの使用例は次のようになります。

pr:
  branches:
    include:
    - features/*
    exclude:
    - features/experimental/*
  paths:
    include:
    - **/*.cs
steps:
- script: echo My PR build!

YAMLテンプレートにおいて、インラインで式を使用する

YAMLテンプレートは、パイプラインの一部を再利用する強力な方法です。テンプレート式では、共通コードを抽出するだけでなく、値を変更したり、YAMLの内容を制御したりできます。これまで、テンプレート式はYAML式の値全体を占有しなければなりませんでした。この例は、式がsolutionプロパティの値全体であるように機能します。

- task: msbuild@1
  inputs:
    solution: ${{ parameters.solution }}
We've now relaxed the restriction and allow inline templates like you see in the example below.
- script: echo The solution file is ${{ parameters.solution }}

パイプラインの初期化ログのトラブルシューティング強化

パイプラインが実行されるとき、Azure Pipelinesはパイプラインの定義が正しいことを確認し、スケジュールするジョブを決定し、エージェントがジョブを実行するよう要求しなければなりません。これまでは、このプロセスは不透明であったため、問題が発生した場合、顧客が問題のトラブルシューティングを行うことはほとんど不可能でした。パイプライン初期化ログ(pipeline initialization log)と呼ばれる新しい種類のログが導入され、これらの詳細が表示されます。完成したビルドでDownload all logsオプションを選択すると、パイプライン初期化ログにアクセスできます。

YAMLパイプラインの既定保存期間

私たちはユーザーがYAMLパイプラインの保存ポリシーを設定する方法について取り組んでいます。この新しい機能が利用できるようになるまで、多くのユーザーが以前の既定値である10日間の保存期間を超えてビルドを保存するために、すべてのYAMLビルドのデフォルトの保存期間を30日間に延長しました。新しいモデルが作成されるまで、YAMLパイプラインのエディターで保持タブを削除します。

Linux/ARMと32bit Windowsプラットフォームでビルド

Azure Pipelinesはオープンソースのクロスプラットフォームエージェントであり、64ビット(x64)のWindows、macOS、Linux向けプラットフォームがサポートされています。このスプリントでは、Linux/ARMとWindows/32-bitの2つの新しいプラットフォームをサポート対象にしました。これらの新しいプラットフォームは、Linux/ARMマシンであるRaspberry Piのように、あまり一般的ではないかもしれませんが、重要なプラットフォーム向けに構築できるようになります。

variable groupsの複製

variable groupsの複製サポートが追加されました。variable groupsを複製し、変数を少ししか更新しない場合は、変数を1つずつ追加するという面倒なプロセスを経る必要はありません。variable groupsのコピーをすばやく作成し、値を適切に更新し、新しいvariable groupsとして保存できるようになりました。

Clone variable group

注意事項

シークレットに設定されている変数の値はvariable groupの複製時にコピーされません。variable groupを複製して保存した後、暗号化された値を設定してください。

すべてのソースに作業項目とコミットを関連付けできるようになる

改善されたトレーサビリティへのコミットメントを継続しており、皆さんがパイプラインにリンクされたすべての成果物のコミットおよび作業項目の詳細を表示できるようになったことをお知らせいたします。既定では、コミットと作業項目は同じステージへの最後の展開と比較されます。ただし、必要に応じて、以前の展開と比較できます。

Linked sources

Azure App Service deploymentsでパッケージからの実行をサポート

Azure App Service Deployタスク(4.*)バージョンでは、以前RunFromZipと呼ばれていたRunFromPackageをサポートしています。

App Serviceは、msdeploy(別名WebDeploy)、git、ARMなど、ファイルを展開するためのさまざまなテクニックをサポートしています。 しかし、これらの技術には限界があります。あなたのファイルはwwwrootフォルダー(特にd:\home\site\wwwroot)に配備され、ランタイムはそこからファイルを実行します。

Run From Packageを使用すると、個別のファイルをwwwrootにコピーする展開手順はなくなりました。代わりに、zipファイルを指すだけで、zipは読み取り専用のファイルシステムとしてwwwrootにマウントされます。これにはいくつかの利点があります。

  • ファイルコピーのロックの問題を軽減します。
  • プロダクションアプリにデプロイできます(再起動含む)。
  • アプリで実行されているファイルを特定できます。
  • Azure App Serviceのデプロイメントのパフォーマンスを向上させます。
  • コールドスタート時間の短縮ができます。とくに、npmパッケージツリーが大きいJavaScriptの場合、効果がが大きくなります。

App Server Deploy タスクでLinux コンテナーをデプロイ

Azure App Service Deployタスクの4.*バージョンでは、独自のカスタムコンテナーをAzure Function on Linuxにデプロイできます。

Azure関数のLinuxホスティングモデルは、Dockerコンテナーに基づいています。Dockerコンテナーは、パッケージ固有の依存関係をパッケージ化して活用する柔軟性を高めます。Linux上の関数は2つの異なるモードでホストできます。

  1. Built-in container image:Functionアプリケーションコードを持ってきて、Azureはコンテナー(組み込みイメージモード)を提供し、管理します。したがって、特定のDocker関連の知識は必要ありません。これはApp Service Deployタスクの既存のバージョンでサポートされています。
  2. Custom container image:カスタムコンテナーイメージをLinux上のAzure FunctionsにデプロイするためのApp Service Deployタスクが強化されました。functionに特定の言語バージョンが必要な場合、またはビルトインイメージに含まれていない特定の依存関係や設定が必要な場合は、Azure Pipelineを使用してカスタムイメージをビルドしてLinuxのAzure Functionsにデプロイできます。

Azure Test Plans

Azure Test Runnerクライアントでデスクトップアプリケーションの手動テストを実行

Azure Test Runner(ATR)クライアントを使用して、デスクトップアプリケーションの手動テストを実行できるようになりました。 これにより、Microsoft Test ManagerからAzure Test Plansに移行する時役立ちます。こちらのガイダンスを参照してください。ATRクライアントを使用すると、手動テストを実行し、各テストステップのテスト結果を記録できます。また、スクリーンショット、イメージアクションログ、オーディオビデオ録画などのデータ収集機能も備えています。テスト時に問題が見つかった場合、テストランナーを使用して、自動的にテストステップ、スクリーンショット、およびコメントが含まれるバグを作成します。

ATRでは一度ランナーのダウンロードとインストールが必要です。以下のようにRun for desktop applicationを選択します。

Azure Test Runner Azure Test Runner install

Azure Artifacts

Pipeline Artifactsのパブリックプレビュー

Azure Pipelinesで使用するために設計された非常にスケーラブルな新しいアーチファクトタイプであるPipeline Artifactsのパブリックプレビューをリリースします。 Pipeline Artifactsは、最近発表されたUniversal Packagesと同じテクノロジに基づいており、大規模なエンタープライズクラスビルドのビルド出力の保存に要する時間を大幅に短縮できます。

Wiki

Contribute権限を使用して、コードリポジトリからwikiを発行する

以前は、gitリポジトリでCreate Repository権限を持つユーザーだけがwikiとしてコードを公開することができました。これまでは、リポジトリの管理者または作成者が、git reposでホストされているmarkdownファイルをwikiとして公開しようとする要求に対してボトルネックになっていました。今回の更新でコードリポジトリへのContribute permissionがあれば、コードをwikiとして公開できます。

Administration

PATsでCAPを強制する

2017年2月にAzure Active Directoryの条件付きアクセスポリシー(CAP)のサポートを発表しましたが、個人アクセストークンなどの代替認証メカニズムがCAPを実施しないという制限がありました。私たちはこのギャップを埋めることを発表してくれることを嬉しく思っています。PAT、SSH鍵、代替認証資格とOAuthを使用する場合、Azure DevOpsはCAP IPフェンシングポリシーを守るようになります。管理者はこの機能を利用するために何もする必要はありません。既存のすべてのポリシーに自動的に適用されます。

Next steps

注意事項

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

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

Go to Azure DevOps Services

Feedback

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

Make a suggestion

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

ありがとうございました。

Aaron Bjork

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment