Using Octopus Deploy To Transform Custom ASP.Net Connection StringsDuring Deployment

This process has resulted in us selecting Team City for the CI solution and then Octopus Deploy to deal with our deployment concerns, which in our case is completed by the need to deploy the same release to many different clients but with customised Connection Strings and the like for each client.

Having gone through the process of making all of the necessary configurations to both pieces of software, we were almost ready to attempt a first test deployment. However, as described in the Octopus Documentation, the software for transforming the connection strings within the web.config file are expected to be in the following format:

<connectionStrings>
    <add name="StringName" value="Data Source=DatabaseServer;Initial Catalog=Database;Integrated Security=true" />
</connectionStrings>

Unfortunately, the connection strings within our application could not be defined in this way, and had to be specified as follows:

<connectionStrings>
    <add name="StringName" providerName="System.Data.SqlClient" connectionString="Data Source=DatabaseServer;Initial Catalog=Database;Integrated Security=true" />
</connectionStrings>

This meant that Octopus was unable to transform our connection strings by default. So I turned to another feature of Octopus which is its ability to execute Powershell scripts before, during or after the deployment. Having read the documentation about running this, I created a PostDeploy.ps1 script file within the root of the application package that I wanted to deploy. I then set about figuring out how to update an XML file in powershell.

This turned out to be reasonably easy to do. The variables set for the deployment within the Octopus Web Portal are available within the hash table in the powershell script, within the variable $OctopusVariables. All I had to do was find the connection string element, with the name attribute equal to the key within the OctopusVariables and then update the connectionString attribute with the value stored in the hash table.

The PostDeploy.ps1 script that I created can be found on GitHub Gist.

So far, using Octopus Deploy has been excellent and I can see already that it will save me personally, as the person responsible for making releases, masses of time and aggravation ensuring all connection strings are set properly for each client.