Improved pipelines security with read-only variables

With this update, we are improving pipelines security with read-only variables. In addition, you can now define output variables in your tasks within any lifecycle hook of a deployment job and consume it in downstream steps and jobs within the same stage.

Check out the Features list below for details.

Features

General:

• Restrict organization creation via Azure AD tenant policy

Azure Pipelines:

Note

Installing .NET 4.6.2 or higher is required for VSTest task to work properly on build agents.

• Read-only variables
• Support for output variables in a deployment job
• Avoid rollback of critical changes
• Removing older images in Azure Pipelines hosted pools

General

Restrict organization creation via Azure AD tenant policy

Azure DevOps administrators can now leverage a new Azure AD policy. This policy will let you restrict creating new Azure DevOps organizations connected to your company's Azure Active Directory. To learn more about the policy, see the documentation here.

Azure Pipelines

Read-only variables

System variables were documented as being immutable, but in practice they could be overwritten by a task and downstream tasks would pick up the new value. With this update, we tighten up the security around pipeline variables to make system and queue-time variables read-only. In addition, you can make a YAML variable read-only by marking it as follows.

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

Support for output variables in a deployment job

You can now define output variables in a deployment job's lifecycle hooks and consume them in other downstream steps and jobs within the same stage.

While executing deployment strategies, you can access output variables across jobs using the following syntax.

• 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-latest'
  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-latest'
  variables:
    myVarFromDeploymentJob: $[ dependencies.A.outputs['deploy_10.setvarStep.myOutputVar'] ]
  steps:
  - script: "echo $(myVarFromDeploymentJob)"
    name: echovar

Learn more on how to set a multi-job output variable

Avoid rollback of critical changes

In classic release pipelines, it is common to rely on scheduled deployments for regular updates. But, when you have a critical fix, you may choose to start a manual deployment out-of-band. When doing so, older releases continue to stay scheduled. This posed a challenge since the manual deployment would be rolled back when the deployments resumed as per schedule. Many of you reported this issue and we have now fixed it. With the fix, all older scheduled deployments to the environment would be cancelled when you manually start a deployment. This is only applicable when the queueing option is selected as "Deploy latest and cancel others".

Removing older images in Azure Pipelines hosted pools

On March 23, 2020, we will remove the following images from our Azure Pipelines hosted pools.

• Windows Server 2012 R2 with Visual Studio 2015 (vs2015-win2012r2)
• Mac OS High Sierra 10.13 (macOS-10.13)
• Windows Server Core 1803 (win1803)

By removing these images, we will continue to roll out newer image versions more efficiently.

To learn more about the removal of these images, check out the removing older images in Azure Pipelines hosted pools blog post.

Next steps

Note

These features will roll out over the next two to three weeks.

Head over to Azure DevOps and take a look.

Go to Azure DevOps

How to provide feedback

We would love to hear what you think about these features. Use the help menu to report a problem or provide a suggestion.

You can also get advice and your questions answered by the community on Stack Overflow.

Thanks,

Vijay Machiraju