1

I have reached the point where I have to get my Service Fabric Cluster deployed to Azure :) Besides the the stateful/stateless services I have 2 MVC applications. I currently have a few settings in the web.config files (mostly connection strings).

I plan to configure continuous build / deploy using Visual Studio Online, but have not dogged into to doing that yet.

Where are the recommended place to store the configuration settings. I will need settings for 3 different environments (dev/test/prod).

I found a reference, at some point, to store the settings on the build definition which sounds like a better place to store production credentials than in config files that are being part of the source code for the applications. I need to limit access to values for the production environment and having them in the config files that all developers has access to does not sound like the best way to do this.

Any white papers or best practices regarding this I should be aware of?

Tony
  • 1,394
  • 5
  • 22
  • 48
  • https://stackoverflow.com/questions/33928204/where-do-you-set-and-access-run-time-configuration-parameters-per-environment-fo I store my config values using a method similar to that, then use token replace on VSTS before publishing. There may be a better way, so I am not posting this as an answer! – Mardoxx Jun 13 '17 at 15:45
  • Thank you. I think that is the only way to avoid having production password as part of the source code which is a big big no go – Tony Jun 14 '17 at 12:39
  • After some consideration I have concluded that it is better to store the values in an azure key vault. This will allow me better options for scripting/deploying/testning compared to maintain the values in a build definition. – Tony Jul 12 '17 at 07:43

1 Answers1

1

You can use de publish profiles and application parameters of the service fabric project to store your settings for each environment.

In my case i have a dev, a homolog and a production environment with different database connection strings, so i created publish profiles named Cloud.Homolog.xml, Cloud.Production.xml and for dev environment i'm still using Local.5Node.xml.

Then, when i want to deploy in some of this environments i choose the correct publish profile.

Here is the documentation for multiple environment management:

Link

Renan Fagundes
  • 86
  • 3
  • 1
    I am not happy with that solution as production password will be checked in to the source control system and that is exactly what I want to avoid. Thank you for the link btw. It does contain a lot of use full information. – Tony Jun 14 '17 at 12:38
  • This is the solution I am going with combined with storing the appsettings in an Azure Vault. This way that information is kept confidential because it will not be checked into source control, as the code only will hold references to keys instead the values. https://learn.microsoft.com/en-us/azure/service-fabric/service-fabric-application-secret-management – Tony Jul 12 '17 at 07:26
  • Key vault is very interesting too, if you discover how to store passwords in key vault and combine with this, please share you solution, because i had already tried to store in key vault but i didn't discovered how to access the key vault and recover this value. – Renan Fagundes Jul 12 '17 at 12:27