Skip to content

Instantly share code, notes, and snippets.

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

読み取り専用variablesを使用してパイプラインのセキュリティを改善する

今回のアップデートでは、読み取り専用variables(訳注:変数)を使用してパイプラインのセキュリティを改善しています。さらに、展開ジョブのライフサイクルフック内のタスクで出力変数を定義し、同じステージ内のダウンストリームステップとジョブでそれを使用できるようになりました。

詳細については、以下の機能リストをご覧ください。

Features

General:

Azure Pipelines:
注意事項

ビルドエージェントでVSTestタスクがworkプロパティを参照するには.NET 4.6.2かそれ以上がインストールされている必要があります。

General

Azure ADテナントポリシーでorganizationの作成の制限をサポートしました

Azure DevOps管理者は、新しいAzure ADポリシーを活用できるようになりました。このポリシーにより、会社のAzure Active Directoryに接続された新しいAzure DevOps Organizationの作成を制限できます。ポリシーの詳細については、こちらのドキュメントをご覧ください。

Azure Pipelines

読み取り専用variables

システム変数は不変であると文書化されていましたが、実際にはタスクによって上書きされる可能性があり、後続のタスクが新しい値を取得していました。今回の更新では、パイプライン変数に関するセキュリティを強化して、システム変数とキュー時間変数を読み取り専用にします。さらに、次のようにマークすることで、YAML変数を読み取り専用にできます。

variables:
- name: myVar
  value: myValue
  readonly: true

展開ジョブで出力variablesをサポートしました

展開ジョブの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: echovar

set a multi-job output variableをみてください。

致命的な変更による展開がロールバックされることを回避する

従来のリリースパイプラインでは、定期的な更新であれば、スケジュールを設定したdeploymentに依存するのが一般的です。ただし、重大な修正がある場合は、定例外の手動展開での開始を選択できます。その場合、古いリリースは引き続きスケジュールされたままになります。スケジュールにしたがって展開が再開されると、手動展開がロールバックされてしまうという課題がありました。多くの方がこの問題を報告しており、現在修正しています。今回の修正により、環境への古いスケジュールされた展開はすべて、手動で展開を開始するとキャンセルされます。これは、キューオプションが"Deploy latest and cancel others"として選択されている場合にのみ適用されます。

Azureパイプラインのホストプールから古いイメージを削除しました

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というブログをみてください。

Next steps

注意事項

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

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

Go to Azure DevOps Services

Feedback

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

Make a suggestion

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

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

Vijay Machiraju

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