If I recall correctly, Azure Devops was set to add a feature to allow release pipelines to be placed into yaml , similar to build pipeline. Is this feature available yet?
Im hoping to get some guidance on the migration of legacy classic release pipeline, to the new format?
UPDATE: It looks like I'm only about 4 months behind. Posted on May 6, 2019
With our new updates, development teams can now leverage the same YAML documents to build multi-stage pipelines-as-code for both Continuous Integration and Continuous Delivery. This was one of the biggest requests from our customers
here are some helpful links for those that are like me : have many classic release pipelines manually created, interested in the new format.
https://azure.microsoft.com/en-us/updates/unified-pipelines/
https://azure.microsoft.com/en-us/blog/accelerating-devops-with-github-and-azure/
For migrating release classic pipelines, Azure DevOps still lacks some more straightforward support.
But there is an external tool, yamlizr, for helping migrate many release pipelines.
In my case I had to hack a bit the tool (see its issues if they are still opened).
The result is not production ready, but is still a good starting point from my viewpoint, and helps a lot.
I've discovered that Microsoft provides some built-in help to migrate a release pipeline from a classic GUI-based Release pipeline to a YAML-based pipeline.
If you edit your classic GUI-based Release pipeline and drill down to a task, there is a link at top right that says View YAML:
Clicking the link generates the YAML associated with the task. Unfortunately it doesn't include the field values. Instead it uses variables and doesn't specify the values of those variables:
steps:
- task: IISWebAppManagementOnMachineGroup#0
displayName: 'IIS Web App Manage'
inputs:
IISDeploymentType: '$(Parameters.IISDeploymentType)'
ActionIISWebsite: '$(Parameters.ActionIISWebsite)'
WebsiteName: '$(Parameters.WebsiteName)'
WebsitePhysicalPath: '%SystemDrive%\inetpub\wwwroot\AspNetDemo'
AddBinding: '$(Parameters.AddBinding)'
Bindings: '$(Parameters.Bindings)'
ParentWebsiteNameForVD: '$(Parameters.WebsiteName)'
VirtualPathForVD: '$(Parameters.VirtualPathForApplication)'
ParentWebsiteNameForApplication: '$(Parameters.WebsiteName)'
VirtualPathForApplication: '$(Parameters.VirtualPathForApplication)'
AppPoolName: '$(Parameters.AppPoolName)'
Luckily the task in the GUI has links against most fields, with field-specific help. That help mentions which variable maps to the field value:
So you can go through each field in the task determining which variable corresponds to each field, to work out what values to add to the YAML snippet.
It's a bit labour intensive but it's quicker than trying to figure it all out from scratch.
Unfortunately there doesn't seem to be any way to view the YAML at the job or stage level, only at the task level. So you'll have to repeat the process for each task. You'll also have to work out the YAML that defines the stage and the jobs yourself.
Create a new multi-stage pipeline-as-code.
https://azure.microsoft.com/en-us/updates/unified-pipelines/
https://azure.microsoft.com/en-us/blog/accelerating-devops-with-github-and-azure/
Related
Added a new VSTS extension to vsts marketplace https://marketplace.visualstudio.com/items?itemName=ManishSingh.soapuiazure&ssr=false#overview
I am able to install this extension on organization but not able to see this in task list to add in pipeline.
Got some way to fixed this on internet like uninstall and reinstall - Didn't worked
Disabled and enable - didn't worked.
The extension uses the deprecated PowerShell v1 execution handler for Azure Pipelines and needs to be upgraded to the Powershell3 execution handler. The v1 handler is from the era of the v1 agent that shipped in 2015 and was replaced by a complete rewrite in the summer of 2016.
##[warning]Task 'SoapUI on Azure' (2.0.6) is using deprecated task execution handler. The task should use the supported task-lib: https://aka.ms/tasklib
For me the task fails to show up in the YAML task helper, but it does show up in the classic UI based pipelines and releases.
You may be able to just make it work when using the Get YAML helper in the classic UI:
steps:
- task: ManishSingh.soapuiazure.5ad1e1bc-7ee6-49c8-b12f-7b7606c5b0e4.SoapUI on Azure#2
displayName: 'SoapUI project.xml'
Then simplify that to:
steps:
- task: SoapUI on Azure#2
displayName: 'SoapUI project.xml'
^^^^
Tested this and it works.
But it looks like this extension could use some love. I already see a few things wrong with it:
Using deprecated task handler
always downloads SOAPUI from blob storage (useful for Hosted agents, but not for persistent agents)
Manifest issues
space in Task Name (task.json)
guid in Task ID (in vss-extension.json)
Some of these are likely unfixable, cause the marketplace makes it very hard to change identifiers once the task is published publicly.
Test to install the same extension and it will show the task: Soap UI on Azure in the task list.
For example:
You can add the task to Agent Job or Deployment Job.
On the other hand, if you are not able to find the task after installing it, you can try to open a Browser InPrivate Window and use the same steps to search the task in Azure Pipeline.
So, recently I set about migrating our Azure Devops Classic Release pipeline to a YAML based one.
What I'm struggling to reproduce is the ability you have with a Classic Release pipeline to select a specific artefact from an associated build pipeline using a dropdown list.
The only way I've found to allow a user to specify a specific artefact is via a parameter, but the definition of dropdown lists is only possible if you know all of the values that will be in the list.
This link is the closest thing I've found that resolves the issue, but even this doesn't allow the specification of a dropdown: https://www.huuhka.net/runtime-artifact-selection-in-azure-pipelines-yaml/
Anyone know how to do this, or even if it is possible?
Ok, so I didn't quite answer the question I posed, but I found an answer that solves the issue I have.
The problem I had is that I want a user to be able to select a specific build at release time.
This is poorly documented and it was a surprise when I saw it working.
In your release pipeline specify a resource:
resources:
pipelines:
- pipeline: YourBuildPipelineReference
source: "Your Build Pipeline Name"
Now when you come to run your pipeline you see the following:
Click Resources and you are now taken to list where you can select a specific build.
Didn't see this before, but I figure lots of people will need this.
For my team where we have partner teams providing us SW pieces that need to be integrated on HW systems and tested together, our code footprint is small and hence churn is small, while number of changes from partner teams is frequent. In such a scenario, I see the need to trigger the release part of the yaml many more times than the build part. Is multi-stage pipelines the way to go? I want to trigger new release instances using RestAPI invoke only the Release stages on the YAML file, using AzureDevOps Rest API.
Regards,
You don't have to use multi-stage pipelines to be able to trigger repeated releases, it just makes the management of the pipeline cleaner.
It's possible to create a pipeline that include a build stage and release stages for each of your environments, trigger the build stage (manually or based on a CI trigger), and then from that Pipeline "Run", deploy as many times as you see fit to whatever environments you like. That can be done from API or portal.
It's also possible to create a pipeline that is "release-only" - that is, it gets created manually, or as the result of seeing a specified build having been run.
Personally, I like the multi-stage build because it's a little easier to see what build created the release that you're deploying around. It's not a requirement, though.
I would like to move the existing Azure DevOps pipelines to YAML based for obvious advantages. The problem is there are many of these and each one has many jobs.
When I click around in Azure DevOps, the "View YAML" link only appears for one job at a time. So that's gonna be a lot of manual work to view YAMLs for each pipeline x jobs and move that to code.
But for each pipeline there seems to be a way to "export" the entire pipeline in json. I was wondering if there is a similar way to at least dump the entire pipeline as YAML if not an entire folder.
If there is an API which exports the same then even better.
Until now, what we supported is what you see, use View YAML to copy/paste the definition of agent job. There has another workaround to get the entire definition of one pipeline is use the API to get the JSON from a build definition, convert it to YAML, tweak the syntax, then if needed, update the tasks which are referenced.
First, use Get Build Definition api to get the entire definition
of one pipeline.
Invoke JSON to YAML converter. Copy/paste the JSON of definition
into this converter.
Copy the YAML to a YAML editor of Azure Devops. Then the most important step is tweak the syntax.
Replace the refName key values with task names and version. For this, you can go our tasks source code which opened in github, built in tasks can be found there(note: please see the task.json file of corresponding task)
Noted: Use this method has another disadvantage that you need very familiar with YAML syntax so that you can tweak the content which convert from JSON successfully.
This is done and there is blog post about exporting pipelineas YAML on devblogs
It's it worth to mention that the new system knows how to handle every feature listed here:
Single and multiple jobs
Checkout options
Execution plan parallelism
Timeout and name metadata
Demands
Schedules and other triggers
Pool selection, including jobs which differ from the default
All tasks and all inputs, including optimizing for default inputs
Job and step conditions
Task group unrolling
In fact, there are only two areas which we know aren’t covered.
Variables
Variables defined in YAML “shadow” (hide) variables set in the UI. Therefore, we didn’t want to export them into the YAML file in case you need an ability to alter them at runtime. If you have UI variables in your Classic pipeline, we mention them by name in the comments to remind you that you need to configure them in your new YAML pipeline definition.
Timezone translation
cron schedules in YAML are in UTC, while Classic schedules are in the organization’s timezone. Timezone handling has a lot of sharp edges, so we opted not to try to be clever. We export the schedule without doing any translation, so your scheduled builds might be off by a certain number of hours unless you manually modify them. Here again, we make a note in the comments to remind you.
But there won't be support for release pipelines:
No plans to do so. Classic RM pipelines are different enough in their execution that I can’t make the same strong guarantees about correctness as I can with classic Build. Also, a number of concepts were re-thought between RM and unified YAML pipelines. In some cases, there isn’t a direct translation for an RM feature. A human is required to think about what the pipeline is designed to accomplish and re-implement it using new constructs.
I tried yamlizr https://github.com/f2calv/yamlizr
It works pretty well for exporting Release Pipelines, except it doesn't export out Pre/Post deployment conditions. We use these for Approval gates. So hopefully in a future release it will be supported.
But per Microsoft they won't support the export to YAML for Release Pipelines it sounds like.
https://devblogs.microsoft.com/devops/replacing-view-yaml/#comment-2043
I'm using an Azure DevOps Pipeline to release an ASP.NET MVC system to an Azure Web App.
I've configured the build not to apply the XML transforms, so I can apply them later, during the release step, and the same build artefact can be released to multiple environments.
The build works fine, and I end up with an artefact containing an untransformed web.config, and the environment-specific transform files.
The Azure App Service Deploy task has a check-box called XML Transformation, which displays the following help text:
The config transforms will be run for *.Release.config and
*.<EnvironmentName>.config on the *.config file. Config transforms will be run prior to the Variable Substitution. XML transformations
are supported only for Windows platform.
At the moment I'm trying to set up a release into a test environment, but the Web.Release.config is being applied, rather than the Web.Test.config. I've searched everywhere I can find for a place to define the environment to make the release use the test config, but I can't find anywhere.
There's a similar question on GitHub which shows the following screenshot:
Unfortunately mine doesn't look like that:
Am I trying to do the right thing? If so, where do I set the environment?
You need to make sure your stage name is just 'Test' and not 'Deploy EMS to Test', reference here.