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.
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
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.
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:
- For canary strategy:
- For rolling strategy :
// 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
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.
These features will roll out over the next two to three weeks.
Head over to Azure DevOps and take a look.
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.