Build in one Org, Release from another with Azure DevOps

Dave Lloyd
ObjectSharp (a Centrilogic Company)
4 min readJun 24, 2019

We recently had a request to deploy a build artifact created in one Azure DevOps organization to a different Azure DevOps organization. The request came from a client that has the git repo in their Azure DevOps org (we’ll call this org1) and will be using Azure Pipelines to build and deploy to their Dev and test environments. However once the build passed a particular stage it would be deployed to a customers environment for UAT using the customers Azure DevOps organization. (we’ll call this org2) The ask was ”can we trigger the release in another organization to deploy a build artifact in our organization”

A Summary of our Solution

We created a build artifact in org-1 and published it to org-2’s Azure Artifacts as a universal package. Then the release pipeline created in org-2 could trigger automatically on creation of the artifact via the continuous delivery option on their release. Or the customer could release any build, at anytime manually. The great thing about this solution is the release of the artifact from org-1 is now in the hands of org-2.

Here are the details

To publish an artifact to another organization, there are two things you need to do in org-2.

  1. You will require a PAT (Personal Access Token) for org-2. Here is how to create a personal access token.
  2. You need to set up a universal feed in org-2’s Azure Artifacts. Creating a universal feed.

Once you have these two things set up. You can use Azure CLI to publish the artifact.

New to the Azure CLI is an azure-devops extension that lets you script Azure DevOps operations such as publishing an artifact.

Lets cut to the chase, here is the script we created to execute the operation.

echo “Loading Azure DevOps extension”az extension add —-name azure-devopsecho “Connect to external Azure DevOps with personal access token”export AZURE_DEVOPS_EXT_PAT=$(pat)echo $AZURE_DEVOPS_EXT_PAT | az devops login —-org $(org)echo “Publish Artifact to external organization”az artifacts universal publish —-organization “$(org)” —-feed “$(feed)” —-name “$(name)” —-version “$(version)” —-description “$(description)” —-path “$(path)”echo “Done”

Command Line Arguments

Here are the 7 command line arguments required for this script.

  • $(org) — The URL for org-2 {http://dev.azure.com/org-2}
  • $(pat) — A Personal Access Token for org-2
  • $(feed) — The name of the Azure Artifacts universal feed in org-2
  • $(name) — The name of the artifact
  • $(version) — The artifacts version number $(Build.BuildNumber)
  • $(description) — A description of the artifact
  • $(path) — The path to the artifact to publish

Tip: Wrap the first three in a variable group. Here is a great article on using Variable groups by Kelli Mohr in case you’re new to them.

We added the script to an inline shell script task. Then wrapped it up in a Task Group so we could reuse it easily and just pass the arguments into the task from our Build or Release.

If you publish the artifact from your build you will likely want to include your task group to publish to org-2 as well as a Publish Artifact task to publish to org-1 for deployment there also.

The more likely scenario is, you will publish locally to org-1 from the build and after some validation and approvals one of your release stages will contain the task that publishes to org-2.

End Result

You can add your task group to any build or release in org-1 and it will publish your build artifact to org-2. In org-2, your release will simply pull the artifact from the Azure Artifacts universal feed you created.

Adding an artifact to a release

Now org-2 can deploy your artifact either via continuous delivery or manually when they are ready.

Warning

At the time I wrote this article az artifacts writes out a warning. Warning: Universal Packages is currently in preview. The product team has since submitted a pull request to remove the warning. However, if you get the warning, it will cause the step to fail when you select “Fail on Standard Error” in the Azure Pipelines task, even though it was successful.

Dave Lloyd is a consultant with, and one of the original co-founders of, ObjectSharp. ObjectSharp is Toronto’s premier cloud-first digital transformation company, with particular expertise in the Microsoft Azure stack. A truly end-to-end solutions provider — from product ideation, to user experience design, to cloud-first and serverless application architecture and development, on through to DevOps, governance and data protection — we are your one-stop shop for succeeding and leading with cloud solutions. To learn more about ObjectSharp and its expertise in all things DevOps and Microsoft Azure, please visit us at https://objectsharp.com or say hello on Twitter and LinkedIn.

--

--

Dave Lloyd
ObjectSharp (a Centrilogic Company)

I have been writing software and teaching/coaching developers for 40 years. I love sharing knowledge and experience.