Automating Web deployments to Test Environments

Welcome to the latest JenkinsHeaven post!

Today I'd like to talk about how I set up auto-deployment of the web application as it is an important building block in continuous delivery that I have implemented to our internal corporate test environment.

We added some nice features to the environment that are worth telling you about. To get it running smoothly required dealing with some gotchas.

In this environment the target IIS and Jenkins are on the same machine. This is only because we were having firewall issues in a previous environment. The below approach should still work across machines as long as network permissions are in place.

Let's start by outlining what some of these nice features are and then we'll get in to the detail:

• Everyone on the development team, including the testers have the ability to build a Jenkins job to deploy the web application to the Test environment
• The application IIS content directory is completely expunged every time the deployment job is executed
• Redeploying with WebPublish and MSBuild
• The minor assembly version number (Properties/AssemblyInfo.cs) is incremented and automatically committed back to TFS source control every time the deployment job is executed

I'll be referring to scripts that I have opensourced here. This is where I will continue to add new scripts and make improvements.

1. Everyone can deploy

I used Jenkins own database to create user accounts and simple passwords for each team member and then used Project-based Matrix Authorization Strategy which is part of the Matrix Authorization Strategy plugin to control access (Overall Read permission at global level).

I then created a job called "DeployToTestEnv" and gave users Read and Build permission in the job config

While this does mean that the testers still need to ask the developers if it the code is stable to deploy each and every time they think about deploying, this minor pestering is far outweighed by the benefit of being able to DEPLOY AT WILL!

In a perfect world, the DeployToTestEnv job would only every run after the main job that runs all the tests on each commit had run successfully, but I was overruled and told the testers must be able to "press a button to deploy".

2. Expunging everything on every deploy

Now we are starting to get into what the job actually does. To ensure that you have deleted ALL the files and folders recursively from the target IIS, I user the IISController.bat script to stop the website and also stop the application pool. I found that if I didn't stop the application pool some files and folders remained locked. As soon as I stopped both, everything could be removed with DeleteSiteFiles.bat.

3. Redeploying with WebPublish and MSBuild

Redeploying is easy with the Deploy.bat script. I pass in 3 parameters. The solution file name (path relative to workspace root), the configuration (usually release) and Publish Profile name (previously set up and connection tested with a user that has management rights on the target IIS.). The web.config. file should probably update the connection string (at a minimum). Have a read of this and this.

In the past I have stopped here and felt pretty good about myself. In our environment, the testers are sitting in an office away from the rest of the team. Its only 5 paces away but that glass wall and door is a barrier. As a result of this, the testers are raising bugs unfinished stories.

4. Auto-increment of minor version number

To combat this and know what version of the application the testers are testing and the dev team is developing, we instituted automatic incrementing of the minor version number in the Properties/AssemblyInfo.cs file. This was achieved in two parts. Firstly, I downloaded and installed this and added it as a project in the solution. Secondly, I run the IncrementMinorVersion.ps1 script as a PowerShell Build Step in Jenkins. This script will checkout the file, increment the minor version number and reliably check the change back to TFS source control. Powershell is cool! The effect is that the minor version number increments by 1 AFTER each deployment to test so that the development team is immediately working on the next release.

Thanks for reading and hopefully you have found this helpful. As always, if you have any questions, feedback or comments leave them in the comments section below.

Till next time...