Usage of Azure DevOps universal packages to store/apply MsDyn365FO binary (platform) update
Azure DevOps universal packages are currently in public preview as you can read here: https://docs.microsoft.com/en-us/azure/devops/artifacts/quickstarts/universal-packages?view=vsts&tabs=azuredevops
"Universal Packages store one or more files together in a single unit that has a name and version." This kind of artifact is perfect to store binary (platform) update of MsDyn365FO inside Azure DevOps.
Before we discovered universal packages, we simply checked-in the binary (platform) updates which our current extensions/customizations rely on. With this process we had some problems in context of duration to perform get-latest and disk space on build VMs. The reason behind the need to check-in the binary (platform) updates is that we have an automation in place to install these updates on development VMs which are not connected to LCS. And the reason why we cannot simply download the desired asset from LCS during our automation is that there is currently no API to do this.
Before you can up- and download universal packages you have to install VSTS CLI using the following URL: https://aka.ms/vsts-cli-windows-installer
After the installation you have to create a personal access token to login to Azure DevOps using VSTS CLI with the following PowerShell command:
# Login
vsts login --instance https://dev.azure.com/[your-organization] --token [your personal access token]
# Set [your-organization] as CLI's default
vsts configure -d instance=https://dev.azure.com/[your-organization]
After the login is done you can prepare the binary (platform) update you want to upload to Azure DevOps as universal package. I usually place the zipped packed in an folder under C:\Temp as you can so in the following screenshot:
Another preparation step for the upload is to create a feed under Azure DevOps Artifacts which you use as target for the upload. I created (as you can see in the banner of this post) a feed with the name BinaryPackages. After this is also done you can use the following PowerShell command to upload the binary (platform) update as universal package. I would recommend to use the product or platform build number which you can see in the LCS asset library for the version parameter. Because the displayed version number is not a semantic version, you have to delete the last dot (before 8.1.170.20004 after 8.1.17020004).
vsts package universal publish --instance https://dev.azure.com/[your-organization] --feed BinaryPackages --name 81_binary_package --version 8.1.17020004 --description "8.1 Binary Package" --path C:\Temp\AXPlatformUpdate
When your package is available via universal packages your Azure DevOps should look similar to what you can see in the banner of this post and you can now use this artifakt for manuall downloads or for any kind of automation to install the package on VMs. The PowerShell command to download the binary (platform) update to your C:\Temp folder is the following:
vsts package universal download --instance https://dev.azure.com/[your-organization] --feed BinaryPackages --name 81_binary_package --version 8.1.17020004 --path C:\Temp
I've been googling on how to incorporate a CICD usage of Universal Packages and stumbled upon this. We would typically have several iterations before releasing a final version, so we keep the same version number until it's "ready". I didn't think about leveraging the patch version and adding a few digits. I also didn't anticipate finding the answer on LinkedIn of all places. Call me doubly surprised! Thank you for sharing this. Albeit 3 years ago, it's still relevant! For those curious, I'm using UP to store a web artifact that is npm-managed, but one I'd call an end-user package that's not like a normal npm package you would consider an upstream dependency, but more so a "consumer". It's a JavaScript React app that consumes other npm packages and is transpiled down to browser-digestible files to render a web application.
Ok, I see now that the dependency on semantic versioning is built into the Universal packages feature: https://docs.microsoft.com/en-us/azure/devops/pipelines/artifacts/universal-packages?view=vsts&tabs=designer#package-versioning
Nice, Paul! You're on a streak. Keep it coming. I love it! I suspect another reason you're looking into this is because your dev VMs are mostly (of not all) downloaded VHDs, so servicing them through LCS is not an option, right?