This is the second 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 (this post)
- 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
When hosting projects in Azure, for example in an App Service, it is possible to use deployment slots. Along with its other benefits, deployment slots can also act as a backup. If the deployment is done by swapping slots, the previous version will be ‘backed up’ on a different slot and can be reverted in case of issues.
But in the case of on-premise deployments, this is not an option. One solution would be to create a backup of the project files before deployment into a different folder.
This post will cover how the backup process can be implemented inside a task group, which can be used across multiple releases.
Variables
The task group leverages multiple variables that can be set up either as variable groups or as release variables.
- ApplicationName = $(Release.DefinitionName)$(EnvironmentSuffix)
- ApplicationsBackupRootPath = $(ApplicationsRootPath)-backup
- ApplicationsRootPath = c:\Applications\$(ProjectGroup)$(EnvironmentSuffix)
- EnvironmentSuffix = -staging
- ProjectGroup = TestProjectGroup
- RootPath = $(ApplicationsRootPath)\$(Release.DefinitionName)
Given a project named TestProject, the staging environment and a Release named TestProjectRelease, the values for the variables would be:
- ApplicationName = TestProject-staging
- ApplicationsBackupRootPath = c:\Applications\TestProjectGroup-staging-backup
- ApplicationsRootPath = c:\Applications\TestProjectGroup-staging
- EnvironmentSuffix = -staging
- ProjectGroup = TestProjectGroup
- RootPath = c:\Applications\TestProjectGroup-staging\TestProject
Task group
1. The first task checks if the project’s folder actually exists because when deploying for the first time, there is nothing to back up. The result of the task is a variable called RootPathExists that will be used to determine whether the other tasks should run or not.
2. The second task sets another variable, BackupFolderwhich is the destination folder where files should be backed up.
Using the example values, the value would become
c:\Applications\TestProjectGroup-staging-backup/TestProject-staging/TestProject_taken_before_Release-1
Release.ReleaseName is a predefined DevOps release variable. This is unique per release, ensuring that the archive file name will also be unique.
3. The third tasks copies the project files to the backup folder.
Notice that there is a custom condition at the bottom. This task is executed only if the previous tasks was successful and the value of the RootPathExists variable is True, meaning that only if the source folder exists. All the other tasks after this one have the same custom condition set.
4. The fourth task zips up the backup folder
5. The final task deletes the backup folder as that is not needed anymore.
An improvement to this process would be to remove old backups (for example older than 6 months) to avoid them piling up and using a lot of disk space. This could be the 6th task.
