Azure DevOps CI/CD for Windows Desktop Apps – Part 4

The Release Pipeline

To create a release pipeline, you need to specify one or more artifacts you want to use (the output of the previous “build pipeline”), then you setup your “stages” where each stage has again a set of tasks.

There are more parts available:
Azure DevOps CI/CD for Windows Desktop Apps – Part 1
Azure DevOps CI/CD for Windows Desktop Apps – Part 2
Azure DevOps CI/CD for Windows Desktop Apps – Part 3
Azure DevOps CI/CD for Windows Desktop Apps – Part 4 (this post)
Azure DevOps CI/CD for Windows Desktop Apps – Part 5

Once you have selected the artifact(s), click on the corner icon to configure the trigger:

As you can see in the screenshot, I configured the trigger to look for the build tag “win-publish”. Revisit part 3 of this installment to see the actual PowerShell script which adds this tag to the pipeline.

So, now we have a triggered, continuous deployment trigger. Great!

Next step: create the release pipeline and make sure specific stages need approval. To do this, create your stages and click on the edge area of the stage to edit triggers and approvals.

Stages in a Release Pipeline

For web apps, stages are mostly used for test, staging and production slot based deployments. For Windows Desktop apps, this doesn’t make a lot of sense but nobody says you can’t use stages for other logical grouping of tasks. My main motivation for this was the capability to do approvals between those stages.

Here’s an overview of all the stages I have in my release pipeline:

• Create Deployable
  • Prepare “output” directory (get all translation files, make sure help files and other files necessary for deployment are available)
  • Obfuscate assemblies
  • Create MSI and ZIP package
• Approval
  • Before the next stage is executed, I need to approve first by clicking on a link in an email).
  • This allows me to inspect and test the MSI/ZIP file and also send this build privately to customers in order to find out if a particular issue has been resolved.
• Create Files and Upload
  • This stage creates some metadata files (like readme files, html files, xml files) I need for publishing my release to the public.
  • The MSI and ZIP file will also be uploaded to the public servers.
• Approval
  • Before I go ahead and execute the next stage, I want to make sure everything works. I can now send out download links internally or to a larger group of customers/testers.
• Publish App
  • This stage will execute scripts to update the web site and knowledge base articles with the files created in the previous stage.
  • XML files for the update check will be uploaded.
  • Chocolatey pack and push will be executed.
  • Release notes will be updated.
• Publish Help
  • This stage runs automatically after the previous stage (without approval) and will upload the HTML help files to the public web servers.

You may wonder, why so many stages and why setting them up this way?

Your requirements may be different but keep in mind that you can easily re-deploy any stage. So it makes sense to split them up in logical blocks for easy re-runs. Especially when you author the stages or troubleshoot them, it’s helpful to have smaller pieces to re-deploy.

That’s it for Part 4. Stay tuned for Part 5…