|
| 1 | +--- |
| 2 | +author: sid-ah |
| 3 | +ms.author: simerzou |
| 4 | +ms.technology: devops-release-notes |
| 5 | +ms.date: 4/13/2020 |
| 6 | +ms.topic: include |
| 7 | +--- |
| 8 | +### Depend on job output variable from another stage |
| 9 | + |
| 10 | +Output variables may now be used across stages in a YAML-based pipeline. This helps you pass useful information, such as a go/no-go decision or the ID of a generated output, from one stage to the next. The result (status) of a previous stage and its jobs is also available. |
| 11 | + |
| 12 | +Output variables are still produced by steps inside of jobs. Instead of referring to `dependencies.jobName.outputs['stepName.variableName']`, stages refer to `stageDependencies.stageName.jobName.outputs['stepName.variableName']`. Note: by default, each stage in a pipeline depends on the one just before it in the YAML file. Therefore, each stage can use output variables from the prior stage. You can alter the dependency graph, which will also alter which output variables are available. For instance, if stage 3 needs a variable from stage 1, it will need to declare an explicit dependency on stage 1. |
| 13 | + |
| 14 | + |
| 15 | +### Limit what repos the build service identity can access |
| 16 | + |
| 17 | +Azure Pipelines can now scope down its repository access to just the repos required for a YAML-based pipeline. This means that if the pipelines's access token were to leak, it would only be able to see the repo(s) used in the pipeline. Previously, the access token was good for any Azure Repos repository in the project, or potentially the entire collection. |
| 18 | + |
| 19 | +This feature will be on by default for new projects and organizations. For existing organizations, you must enable it in <b>Organization Settings</b> > <b>Pipelines</b> > <b>Settings</b>. When using this feature, all repositories needed by the build (even those you clone using a script) must be included in the <a href="https://docs.microsoft.com/azure/devops/pipelines/yaml-schema?tabs=schema%2cparameter-schema#repository-resource">repository resources</a> of the pipeline. |
| 20 | + |
| 21 | + |
| 22 | +### Getting details at runtime about multiple repositories |
| 23 | + |
| 24 | +When a pipeline is running, Azure Pipelines adds information about the repo, branch, and commit which triggered the run. Now that YAML pipelines support multi-checkout, you may also want to know the repo, branch, and commit which were checked out for other repositories. This data is available via a runtime expression which you can map into a variable. For example:<pre><code><div>resources:</div><div> repositories:</div><div> - repository: other</div><div> type: git</div><div> name: MyProject/OtherTools variables:</div><div> tools.ref: $[ resources.repositories['other'].ref ]<br></div><div><br></div><div>steps:</div><div>- checkout: self</div><div>- checkout: other<br>- bash: echo "Tools version: $TOOLS_REF"<br></div></code></pre> |
| 25 | + |
| 26 | + |
| 27 | +### Multi stage pipelines GA |
| 28 | + |
| 29 | +Multi-stage pipelines UI is now generally available. The corresponding preview feature toggle has been removed. |
| 30 | + |
| 31 | +You can navigate to the new experience by selecting **Pipelines** -> **Pipelines** under the left navigation menu in Azure DevOps. This experience is the entry point for both classic build pipelines as well as YAML pipelines. It is mobile-friendly and brings various improvements to how you manage your pipelines. You can drill down and view pipeline details, run details, pipeline analytics, job details, logs, and more. |
| 32 | + |
| 33 | +To learn more about the multi-stage pipelines user experience, see the documentation <a href="https://docs.microsoft.com/azure/devops/pipelines/get-started/multi-stage-pipelines-experience?view=azure-devops" style="cursor:pointer;text-decoration:underline;outline:0px;">here</a>.</p><div style="margin:16px 0px 0px;color:rgb(23, 23, 23);font-family:"Segoe UI", SegoeUI, "Segoe WP", "Helvetica Neue", Helvetica, Tahoma, Arial, sans-serif;font-size:16px;"><br></div><br></div> |
| 34 | + |
| 35 | + |
| 36 | +### Configure Deployment Strategies from Azure Portal |
| 37 | + |
| 38 | +With this capability, we have made it easier for you to configure pipelines that use deployment strategy of your choice, e.g. Rolling, Canary or Blue-Green. Using these out-of-box strategies, you can roll out updates in a safe manner and mitigate associated deployment risks. To access this, click on the 'Continuous Delivery' setting in an Azure Virtual Machine. In the configuration pane, you will be prompted to select details about the Azure DevOps project where the pipeline will be created, the deployment group, build pipeline that publishes the package to be deployed and the deployment strategy of your choice. Going ahead will configure a fully functional pipeline that deploys the selected package to this Virtual Machine. |
| 39 | + |
| 40 | +For more details check out our documentation on <a href="https://aka.ms/AA7jlh8">configuring Deployment Strategies </a> |
| 41 | + |
| 42 | + |
0 commit comments