Since VSTS is Renamed/updated into Azure DevOps, there are some changes in the UI to find those option above.
All the build/Release definition came along with the single term called Pipeline. So there is no need to create a dummy release definition in order to import a new one. You can import a new release definition without having any dummy one.
From reading the comments above the reason you are having issues with importing a Release Definition from a different VSTS/Azure DevOps origanization is because the Release Definition that you exported contains GUID references to objects that do not exist in the organization or project that you are importing the Release Definition into. So, you are going to have to roll up your sleeves and do some work in order to have a successful smooth and fully integrated Release Definition that you can use as a template. We are going to be using the REST API found here: https://docs.microsoft.com/en-us/rest/api/vsts/release/definitions/create?view=vsts-rest-4.1
Here is my technical answer and what I did to duplicate a Release Definition and created a template to be used numerous times:
Export the Release Definition of your choice
Format the JSON in some tool like https://jsonformatter.curiousconcept.com to make it more readable, and then save it in a text file like ReleasePipelineTemplate-Formatted.json
I don't know what components you have defined in your Release Definition, but take a look around and see how GUIDs are used throughout. It might be helpful to create a release definition in order to find the GUIDs that you are going to have to replace.
The GUIDs to find are SYSTEM_COLLECTIONID, SYSTEM_TEAMPROJECTID, SYSTEM_DEFINITIONID, BUILD_QUEUEDBYID
Let us get some variables mentioned above from your build organization and project. In order to get these we need to print some environment variables during a regular build. So, please add a build step somewhere in the beginning of your CI build that adds a "Batch Script" step with the following command "C:\Windows\System32\cmd.exe" and argument "/c set". After the build is done, look into the logs at that build step and find the values for those variables. You will need those in the Release Definition.
You should make a copy before we modify the json file. You should trim down the json file a bit by removing a few things like "createdOn", "modifiedBy", "modifiedOn". At the very bottom is "url" are 3 link. Those needs to modified with the Team Project ID GUID for example. This is just an example of places that need to be modified. Please inspect your own Release Definition.
I'm going to assume you've made the necessary changes to your JSON file and ready to try to import it. Create a PowerShell script called 'CreateReleasePipeline.ps1' with the following script example.
$homeDir = "$(Split-Path -parent $MyInvocation.MyCommand.Definition)"
$VSTS_RestApiHost = "https://vsrm.dev.azure.com/yourpath/_apis"
$VSTS_PAT = "YOUR_PAT_TOKEN_HERE"
$headers = @{Authorization = "Basic " + [System.Convert]::ToBase64String([System.Text.Encoding]::ASCII.GetBytes(":$($VSTS_PAT)"))}
$relDefInfo = Get-Content "$homeDir\ReleasePipelineTemplate-Formatted.json"
Write-Host "Creating Release Pipeline..."
$createReleaseDef = "$($VSTS_RestApiHost)/release/definitions?api-version=4.1-preview.3"
$response = Invoke-RestMethod -Method Post -Uri $createReleaseDef -Body $relDefInfo -ContentType 'application/json' -Headers $headers
Write-Host "Create Release Pipeline done. Pipeline id: $($response.id)"
if ($response.id -gt 0) {
Write-Host "Release definition: succeeded."
}
Write-Host $response.id.\CreateReleasePipeline.ps1
Creating Release Pipeline...
Create Release Pipeline done. Pipeline id: 71
Release definition: succeeded.
71Refresh your Release Pipeline web page and you should see your newly created Release Pipeline.
You can go ahead and re-try until you are satisfied with your results.
I am using this REST API to put a Release Definition template into the source code repository so that I don't have to update 50+ and growing Release Pipelines when I make an adjustment to them. I can a REST API call check if a Release Definition exists, create it if it doesn't, update it if it is not up-to-date. All without having to cramp my hand having to update them manually or create a pipeline when a new get repo is created. I want to automate everything as much as possible. I want to change once or as few as possible and let the system update itself.
Please let me know if this helps.
Leaving this here as an addendum to the accepted answer.
The accepted answer does work, but I should mention that my initial problem wasn't precisely solved by it.
Basically if you don't have any existing release definitions, there doesn't seem to be a way to import definitions. What I did was to create a 'dummy' definition and then follow what the accepted answer says. Creating at least one definition brings you to that screen otherwise you'll only get the screens I show in my question.
