The new ASP.NET documentation under Fundamentals/Working with Multiple Environments it has a detailed description of how to handle multiple environments (surprise surprise) in code.
I was wondering if this is the "best practice" when dealing with multiple environments or should it be handled by something other than code like the tool that is doing the deployment for example?
At my workplace we have many test environments to manage, and we generally run a .NET stack for websites. We currently use Octopus Deploy which, for each environment, will configure applications at deploy time. Our apps are built and packaged up with replaceable variables which Octopus fills in on deployment.
Even if you don't use such a tool I would recommend configuration at deployment time. Your application that you package up (in your CI tool of choice) for deployment should be the same repeatable package that goes into dev, test and prod. We use Team City which builds our deployment packages, and another tool which is a package repository to store all the build artefacts.
Having code paths that are special for an environment potentially makes testing harder since your application is behaving differently.
Continuous integration which compiles all code as it checks in and runs unit tests.
As in point 1 plus variant or parameterized builds. Build for windows server. Build for linux server. Etc.
For internal components or shared assemblies one or multiple private nuget feeds may be desirable.
A devops culture may be useful.
A strategy for continuous deployment of systems composed of subcomponents often tagged as microservices may be useful for asp.net webapi services.
Blue/green deployment may be useful. See http://martinfowler.com/bliki/BlueGreenDeployment.html
