Connection Strings in the Code and Continuous Deployment

Question

I am trying to setup connection string is my Azure resource deployment project. Which will be triggered via Octopus.We would like to have a clean system with every deployment. We want to accomplish Continuous deployment. The projects should cope with changes.And the system should be ready for blue green deployments ?

I am thinking about

• I.Using a load balancer and configurations point to the load balancer with the connection strings.
• II.Have a different database names at every deployment so every resource is unique every time.

What are the challanges I would face ? Do I have to have a tool like ZooKeeper?

Project Structure by TYPE using Azure Resource Project

Parameters & variables focusing to keep them less than 20

Answer 1

I would advise the use of Jenkins in this scenario to achieve continuous deployment. I have implemented this successfully.

There is a feature called poll SCM. This will cause a build when you have a new commit.

After the build, you can use the tool octo.exe to create a release and deploy that release to your specific environment.

I use the following code to create and deploy the release:

Create Release:

octo.exe create-release --project=%Environment% --server %Server% --apiKey %APIKEY% --version %version% --packageversion %version%

My variables are defined at a higher level to provide loose coupling:

%Environment%: Octopus Environment %Server%: Octopus Server %APIKEY%: API Key %Timeout%: Timeout expiry

Deploy Release:

octo.exe deploy-release --project %Environment% --releaseNumber %version% --deployto %Environment% --server %Server% --apiKey %APIKEY% --progress --deploymenttimeout %Timeout%

Jenkins is very flexible and helps a lot in Continuous Deployment. You can have different jobs:

one for green and one for blue

After green is completed, you can trigger one for blue. As for database changes, you can use powershell together with sql cmd to alter your database and/or execute scripts.

Answer 2

In your scenario you can create a deployment slots and use the Auto-swap feature. This will reduce the downtime and risk. See this for more details: Configure Auto Swap

Also, for the first question, you can create 2 databases, one for production and one for staging. You can use sticky settings as shown below to stick a DB to a specific slot. See this: Configuration for deployment slots

Additionally, you can also warm-up your slot so that it is ready to serve requests before it gets swapped.

HTH!