This is the fifth post on this topic. The entire series consists of these posts:
- Part 1: On-premise deployments with Azure DevOps – Introduction
- Part 2: On-premise deployments with Azure DevOps – Backups
- Part 3: On-premise deployments with Azure DevOps – Database Migrations
- Part 4: On-premise deployments with Azure DevOps – Web Applications
- Part 5: On-premise deployments with Azure DevOps – Windows Services (this post)
This post will cover how a Windows Service can be deployed and configured in a task group, which can be used across multiple stages inside a multi-environment release.
Task Group
1. The first task group creates a backup of the service. This is similar to Part 3 and Part 4.
2. The second task applies XML transformations for a custom config file.
The customsettings.config file looks like this:
And for example the transformation file for staging environment (located in Settings\staging\customsettings.staging.config) like this:
The transformation file in this case states that the folders XML element should be replaced entirely. The final customsettings.config file’s content will be:
This is just a simple example, there are more complex transformation that can be done. Check related documentation here.
This task also does variable substitutions for application settings and configuration strings (for the files defined in the Target files field). In Part 4 this was done by default for a Web Application because the DevOps task has built-in support for it, but in case of Windows Services, it has to be done using a separate task.
3. The third task stops the service using the Windows Service Manager DevOps extension.
4. The fourth task deletes the service using the same DevOps extension (it will be created again in Step 6). This is done like this to make sure that on each deployment the service is recreated and any issues should come up during deployment, instead of when starting the service. Another approach is to just stop the service, and just deploy the changes.
5. The fifth task is the on that actually deploys the project files, it copies them from the artifact.
Notice that the Clean Target Folder option is checked to empty the target folder before copying files.
6. Step six recreates the service. As described in Step 4, with the alternate approach this step is not needed.
At this point the service could be started similarly to Stop or Delete steps, but in this case the service is started in a different release stage that is triggered after a pre-deployment approval after making manual checks to see if it is safe to start the service.
