I have been asked to look at creating a Continuous Integration setup whereby our dev team can create feature branches for a client website and have commits to those branches result in that branch being deployed to a Windows Server as it’s own .net website.
Each branch requires its own website as clients want to test features concurrently, so we can’t just merge features with dev or staging main branches to deploy.
Our website projects are build using the .net based Umbraco CMS. We have a project for each client site each in its own GitHub repository. It is a simple mater to use GitHub actions or Microsoft Azure pipelines to monitor a repo and deploy a site to IIS.
What is less obvious is how to get it to deploy multiple copies of a site, one for each feature branch. Each of these sites should exist as independent site’s on Microsoft IIS, and each use the branch name as the subdomain in the host binding so they are each available to the client to be tested.
My solution to this was to create an Azure pipeline that monitors for any commits to a list of branches. The list of branches is defined in the YAML pipeline file which is itself in the website code repository and so can easily be updated by the dev team when they want to create and use a new feature branch.
Any commit’s to any of the nominated branches results in a build of the site and a packaging of all its assets. These are then copied to the server in the test environment by the Azure pipeline agent installed on the machine. Rather than using the Azure pipeline web app deployment script, instead my pipeline instead runs a pre-deployment and a post-deployment windows batch file to create necessary folders and files, as well as the IIS website and bindings.
This approach allows our dev’s to very quickly create feature branches in Git, add their feature branch to the list of monitored branches and commit. This results in an IIS site being created and bound to a new subdomain of the test site’s domain and is available for testing by the client straight away.
The team and continue to work on the branch until they and the clients testing is satisfied, at which point it can be merged with our main dev and staging branches to be published to the main master staging environment for further integrated testing before being pushed to production.
The idea of using a pre-deployment and post-deployment windows batch file, rather than pipeline commands for the pipeline agent directly gives us much more control over the process and allows us to create and destroy IIS sites a required.
The whole process should greatly speed up the velocity of the dev team as they don’t have to think about infrastructure and deployments whilst working on features for clients.