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

Mission

The most important thing for any app is a consistent build/deployment process. I’ve been doing DevOps and CI/CD for many years now and having manual build/release steps is a huge source for errors and issues. Every single time I kick off a build and release, I’m happy and smiling because everything is running smooth and you don’t have to worry about messing things up. But getting there is a real challenge!

---

There are more parts available:
Azure DevOps CI/CD for Windows Desktop Apps – Part 1 (this post)
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
Azure DevOps CI/CD for Windows Desktop Apps – Part 5

---

My latest journey was to move my CI/CD pipeline to Azure DevOps. I had to learn some new stuff, read through docs and went to a lot of trial and errors. So here are my findings…

the app I’m trying to build and Deploy

As you may know, my app “Royal TS” is a Windows Forms based desktop app which helps developers, system engineers, information workers, etc. with easy access to remote systems. Royal TS is a tabbed connection manager with support for Remote Desktop (RDP), VNC, Terminals (SSH, Telnet, Serial Port), Web Pages, PowerShell, Hyper-V, VMware, Event Logs and many more.

My Goal

I’m using Azure DevOps source control (git) for version control and this is my goal:

• push a commit with ‘[win]’ in the commit message to kick off the build of my Windows Desktop app including the unit tests. Since this is a mono repo with other projects (Royal Server, shared libraries, etc.), I want to make sure that only the ‘[win]’ in the commit message triggers the build.
• push a commit with ‘#publish’ in the commit message to kick off the release pipeline from the latest successful build. The release pipeline has several stages and in the end, the MSI file and the ZIP file should be available online, all the other stuff that needs to happen to let users update or download the latest release should also happen.
• once the release pipeline created my MSI file, I want to get an email notification to check if the MSI is OK and to approve the next build stage.
• once my artifacts have been deployed (uploaded on my public web server), I want to get an email notification before I approve the final step to make the new version publicly available. This step is useful to get the build out to some test users to confirm the bug has been fixed or the feature is working as expected before you make it available to everyone.

Sounds easy, right? Well, let’s see…

Build Agent

Since my toolchain includes some 3rd party tools and libraries which must be installed and configured properly, I need my own build agent for that. I installed a Windows Server 2016 VM, nothing fancy, 4 GB of memory and 150 GB of disk capacity.

I also installed:

• Visual Studio 2019 Professional with all the necessary Frameworks, Runtimes and SDKs to build my app
• The obfuscation tool for my post-build pipeline
• The tool to create the MSI package (Advanced Installer)
• The 3rd party libraries which cannot be obtained and licensed using nuget
• Chocolatey
• Azure Pipeline Build and Release Agent

Installing the build and release agent is not as straight forward as you might think. It’s not a matter of double-clicking an installer and click through a wizard. It’s actually quirky as it needs to enter some stuff in the command prompt. It just does not really feel like a Microsoft product. Anyway, it’s not really rocket science and the documentation is quite good.

To install the build agent, open up Azure DevOps in your browser, click the “Gear” icon at the bottom left hand side and then select “Agent pools” unter “Pipelines” (see screenshot below).

In my case I just put my agent in the “Default” pool as my whole build will be handled by this agent. The agent pooling feature is quite powerful. With the agent “Capabilities” (which are also customizable) you could spread out your build pipeline to multiple agents and let each agent with a certain capability participate in the build process. Going into more details here would be far out of the scope of this blog post series.

Anyway, let’s start simple! When you create a new build pipeline, you can specify which agent pool to use:

That’s it for part 1. Now we have the basic infrastructure to run builds on a local agent. In the next post I will go through the build pipeline and show how to control the pipelines to get closer to my goals.