今回のアップデートでは、読み取り専用variables(訳注:変数)を使用してパイプラインのセキュリティを改善しています。さらに、展開ジョブのライフサイクルフック内のタスクで出力変数を定義し、同じステージ内のダウンストリームステップとジョブでそれを使用できるようになりました。
詳細については、以下の機能リストをご覧ください。
General:
Azure Pipelines:
注意事項
ビルドエージェントでVSTestタスクがworkプロパティを参照するには.NET 4.6.2かそれ以上がインストールされている必要があります。
- システム変数を読み取り専用にして、読み取り専用variablesをサポートしました
- 展開ジョブで出力variablesをサポートしました
- 致命的な変更による展開がロールバックされることを回避する
- Azureパイプラインのホストプールから古いイメージを削除しました
Azure DevOps管理者は、新しいAzure ADポリシーを活用できるようになりました。このポリシーにより、会社のAzure Active Directoryに接続された新しいAzure DevOps Organizationの作成を制限できます。ポリシーの詳細については、こちらのドキュメントをご覧ください。
システム変数は不変であると文書化されていましたが、実際にはタスクによって上書きされる可能性があり、後続のタスクが新しい値を取得していました。今回の更新では、パイプライン変数に関するセキュリティを強化して、システム変数とキュー時間変数を読み取り専用にします。さらに、次のようにマークすることで、YAML変数を読み取り専用にできます。
variables:
- name: myVar
value: myValue
readonly: true展開ジョブのlifecycle hooksで出力変数を定義し、同じステージ内の他のダウンストリームステップおよびジョブで出力変数を使用できるようになりました。
展開処理中に、次の構文を使用して、ジョブ間で出力変数にアクセスできます。
- For runOnce strategy:
$[dependencies.<job-name>.outputs['<lifecycle-hookname>.<step-name>.<variable-name>']] - For canary strategy:
$[dependencies.<job-name>.outputs['<lifecycle-hookname>_<increment-value>.<step-name>.<variable-name>']] - For rolling strategy :
$[dependencies.<job-name>.outputs['<lifecycle-hookname>_<resource-name>.<step-name>.<variable-name>']]
// Set an output variable in a lifecycle hook of a deployment job executing canary strategy
- deployment: A
pool:
vmImage: 'ubuntu-16.04'
environment: staging
strategy:
canary:
increments: [10,20] # creates multiple jobs, one for each increment. Output variable can be referenced with this.
deploy:
steps:
- script: echo "##vso[task.setvariable variable=myOutputVar;isOutput=true]this is the deployment variable value"
name: setvarStep
- script: echo $(setvarStep.myOutputVar)
name: echovar
// Map the variable from the job
- job: B
dependsOn: A
pool:
vmImage: 'ubuntu-16.04'
variables:
myVarFromDeploymentJob: $[ dependencies.A.outputs['deploy_10.setvarStep.myOutputVar'] ]
steps:
- script: "echo $(myVarFromDeploymentJob)"
name: echovarset a multi-job output variableをみてください。
従来のリリースパイプラインでは、定期的な更新であれば、スケジュールを設定したdeploymentに依存するのが一般的です。ただし、重大な修正がある場合は、定例外の手動展開での開始を選択できます。その場合、古いリリースは引き続きスケジュールされたままになります。スケジュールにしたがって展開が再開されると、手動展開がロールバックされてしまうという課題がありました。多くの方がこの問題を報告しており、現在修正しています。今回の修正により、環境への古いスケジュールされた展開はすべて、手動で展開を開始するとキャンセルされます。これは、キューオプションが"Deploy latest and cancel others"として選択されている場合にのみ適用されます。
2020年3月23日(訳注:おそらくPST)にAzure Pipelinesのホストプールから以下のイメージを削除します。
- Windows Server 2012 R2 with Visual Studio 2015 (vs2015-win2012r2)
- Mac OS High Sierra 10.13 (macOS-10.13)
- Windows Server Core 1803 (win1803)
これらのイメージを削除することで、新しいイメージバージョンをより効率的に展開し続けます。
これらのイメージの削除の詳細については、removing older images in Azure Pipelines hosted poolsというブログをみてください。
注意事項
ここで議論されている機能は今後二～三週にわたって順次展開されます。
これらの新機能を読んだ後、次のリンクからぜひご自身でAzure DevOpsサービスを体験してみてください。
これらの機能についてどう思っているかお聞きしたいと思います。 フィードバックメニューを使用して問題を報告するか、提案を提出してください。
アドバイスや回答を必要とする質問がある場合、Stack Overflowコミュニティで聞いてください。
ありがとうございました。
Vijay Machiraju