Developer Communityで皆様からいただいたご要望にお応えして、複数の機能を優先的に実装しました。パイプラインでは、YAML式で文字列の分割機能をサポートしました。また、パイプライン実行時の最後のコミットメッセージを表示しないように設定できるようになりました。Delivery Plansでは、チーム数の上限を15から20に引き上げました。
詳しくはリリースノートをご覧ください。
- Delivery Plansで扱えるチーム上限を15から20に増加しました
- Reporting Work Item Links Get APIにあったバグを修正しました
- 新しいBoards Hubのバグ修正を行いました
- パイプライン実行時に最後のコミットメッセージを表示しない設定を追加しました
- Pipelines実行するREST APIでより多くのリソース情報の返却とテンプレートパラメータが渡せるようになりました
- YAMLテンプレート式に文字列のsplit関数のサポートを追加しました
- Gitレポジトリのfetchでtagの同期を無効にできるようになりました
- Ubuntu 18.04イメージのブラウンアウトの予告
Delivery Plansでは、組織内の複数のバックログと複数のチームの表示が可能です。以前は、異なるプロジェクトのバックログやチームが混在する場合など、15チームのバックログを表示することができました。このスプリントでは、上限を15から20に増やしました。
Reporting Work Item Links Get API のバグを修正し、System.LinkTypes.Remote.Related
リンクタイプに対して正しい remoteUrl 値を返せるようにしました。この修正前は、間違った組織名とプロジェクトIDが欠落した値を返していました。
このスプリントでは、New Boards Hub の複数のバグを修正しました。バグ修正の一覧は、New Boards Hub, Sprint 209 updateというブログでご覧いただけます。
今までパイプラインの実行を表示する際、パイプラインUIは最後のコミットメッセージを表示していました。
このメッセージは、たとえば YAML パイプラインのコードがビルドするコードとは別のリポジトリにある場合において混乱することがあります。Developer Communityから、パイプラインを実行するたびに最新のコミットメッセージをタイトルに追加する方法を有効/無効にすることを求める声がありました。
今回の更新では、appendCommitMessageToRunNameという新しい YAML プロパティを追加し、まさにそれを実行できるようにしました。デフォルトでは、このプロパティはtrue
に設定されています。false
に設定すると、パイプラインの実行では、BuildNumberのみが表示されます。
拡張されたPipelines Runs REST APIは、パイプラインの実行で使用される成果物の種類と、その実行のトリガーに使用されるパラメータをより多く返すようになりました。APIを拡張し、パイプラインの実行で使用されるContainer
とpipeline
のリソース、およびテンプレートのパラメータを返すようにしました。例えば、パイプラインが使用するリポジトリ、コンテナ、その他のパイプラインの実行を評価するコンプライアンスチェックを書くことができるようになりました。
以下は、新しいレスポンスボディの例です。
"resources":
{
"repositories":
{
"self":
{
"repository":
{
"id": "e5c55144-277b-49e3-9905-2dc162e3f663",
"type": "azureReposGit"
},
"refName": "refs/heads/main",
"version": "44153346ecdbbf66c68c20fadf27f53ea1394db7"
},
"MyFirstProject":
{
"repository":
{
"id": "e5c55144-277b-49e3-9905-2dc162e3f663",
"type": "azureReposGit"
},
"refName": "refs/heads/main",
"version": "44153346ecdbbf66c68c20fadf27f53ea1394db7"
}
},
"pipelines":
{
"SourcePipelineResource":
{
"pipeline":
{
"url": "https://dev.azure.com/fabrikam/20317ad0-ae49-4588-ae92-6263028b4d83/_apis/pipelines/51?revision=3",
"id": 51,
"revision": 3,
"name": "SourcePipeline",
"folder": "\\source"
},
"version": "20220801.1"
}
},
"containers":
{
"windowscontainer":
{
"container":
{
"environment":
{
"Test": "test"
},
"mapDockerSocket": false,
"image": "mcr.microsoft.com/windows/servercore:ltsc2019",
"options": "-e 'another_test=tst'",
"volumes":
[
"C:\\Users\\fabrikamuser\\mount-fabrikam:c:\\mount-fabrikam"
],
"ports":
[
"8080:80",
"6379"
]
}
}
}
},
"templateParameters":
{
"includeTemplateSteps": "True"
}
YAML パイプラインでリストやオブジェクトのプロパティの各値をループするような、コードの重複を減らす便利な方法を提供します。
ときどき、反復処理するアイテムのセットは文字列として表されます。たとえば、デプロイ先の環境のリストが integration1, integration2
という文字列で定義されている場合です。
Developer Communityからのフィードバックに耳を傾けたところ、YAML テンプレート式にsplit
(訳注:文字列の分割機能)が欲しいという声がありました。
以下のようにsplit
を使うことで文字列を分割し、each
でその部分文字列をそれぞれ反復処理できるようになりました。
variables:
environments: integration1, integration2
jobs:
- job: Deploy
steps:
- ${{ each env in split(variables.environments, ', ') }}:
- script: ./deploy.sh -e ${{ env }}
- script: ./runTest.sh -e ${{ env }}
checkout taskは、Gitリポジトリの内容を取得する際に--tags
オプションを使用します。これにより、サーバーはすべてのタグと、そのタグが指すすべてのオブジェクトを取得することになります。これでは、パイプラインでタスクを実行する時間が増加してしまいます。特に、多数のタグを含む大きなリポジトリを持っている場合です。さらに、shallow fetchオプションを有効にしても、チェックアウトタスクはタグを同期させるので、その目的が達成されない可能性があります。Git リポジトリから取得したりプルしたりするデータの量を減らすために、タグを同期させる動作を制御する新しいオプションをタスクに追加しました。このオプションは、クラシックパイプラインとYAMLパイプラインの両方で利用可能です。
この動作は、YAML ファイルから制御するか、UI から制御するかのどちらかになります。
# Classic
steps:
- checkout: self # self represents the repo where the initial Pipelines YAML file was found
clean: boolean # whether to fetch clean each time
noTags: boolean # whether to prevent sync of tags
fetchDepth: number # the depth of commits to ask Git to fetch
lfs: boolean # whether to download Git-LFS files
submodules: boolean | recursive # set to 'true' for a single level of submodules or 'recursive' to get submodules of submodules
path: string # path to check out source code, relative to the agent's build directory (e.g. \_work\1)
persistCredentials: boolean # set to 'true' to leave the OAuth token in the Git config after the initial fetch
YAMLファイルによるタグの同期を行わないようにするには、チェックアウトステップにnoTags: true
を追加してください。noTags
オプションが指定されていない場合は、noTags: false
が使用されている場合と同じです。
既存の YAML パイプラインの動作を変更したい場合、YAML ファイルを更新するのではなく、UI でこのオプションを設定する方が便利な場合があります。UI に移動するには、パイプラインの YAML エディタを開き、[Triggers]、[Process]、[Checkout] の順に選択します。
この設定を YAML ファイルと UI の両方で指定した場合、UI で指定された値が優先されます。
作成したすべての新しいパイプライン(YAMLまたはクラシック)については、デフォルトでタグは同期されません。このオプションは、既存のパイプラインの動作を変更するものではありません。上記のように明示的にオプションを変更しない限り、それらのパイプラインではタグが引き続き同期されます。
Azure Pipelines は、Microsoft hosted上の Ubuntu 18.04 イメージ (ubuntu-18.04
)を非推奨とします。このイメージは12月1日に廃止される予定です。このため、キューにかかる時間が長くなる可能性があります。
どのパイプラインがubuntu-18.04イメージを使用しているかをよりよく識別するために、ブラウンアウト(訳注:意図的に失敗させること)を計画しています。ブラウンアウト期間中はジョブが失敗します。
- ubuntu-18.04イメージを使ってパイプラインを実行すると警告メッセージが表示されます
- ubuntu-18.04を含む非推奨のイメージを使用しているパイプラインを見つけるためのスクリプトが利用可能です。
- 短期間の「ブラウンアウト」を予定しています。ブラウンアウト期間中はubuntu-18.04の実行は失敗します。そのため、ブラウンアウトの前にパイプラインを移行することをお勧めします。
- 10/7 10:00 UTC - 10/7 16:00 UTC
- 10/14 12:00 UTC - 10/14 18:00 UTC
- 10/21 14:00 UTC - 10/21 20:00 UTC
- 10/28 16:00 UTC - 10/28 22:00 UTC
- 11/4 22:00 UTC - 11/5 04:00 UTC
- 11/11 04:00 UTC - 11/11 10:00 UTC
- 11/18 06:00 UTC - 11/18 12:00 UTC
- 11/25 08:00 UTC - 11/25 14:00 UTC
注意事項
ここで議論されている機能は今後二~三週にわたって順次展開されます。
次のリンクからAzure DevOpsサービスを体験してみてください。
これらの機能についてどう思っているかお聞きしたいと思います。 フィードバックメニューを使用して問題を報告するか、提案を提出してください。
アドバイスや回答を必要とする質問がある場合、Stack Overflowコミュニティで聞いてください。
ありがとうございました。
Aaron Hallberg