How should I handle deploying web applications to multiple servers?Constraints I have a dev, test and prod environment. No build server is available. Developers can't deploy to prod. The people that do deploy to prod copy files from test to prod. They don't have VS installed.Currently The way it's handled is using web.config transform. However, to deploy to prod involves putting prod code on the test server where it's copied over.ProblemSometimes simple mistakes are made, such as forgetting to change test back to the right environment after deployment. Or the test config gets moved to prod instead of the prod config.SolutionSo the question is, what is the best way to prevent mistakes from happening? My first thought is let the app determine which server it's on at runtime and use the appropriate settings/connection strings/etc... However, the server names could change in the not too distant future. So if multiple apps are hard coded, that would mean updating all of them. The easiest way to handle that situation would be to place a DLL in the GAC that determines the environment.Are there any drawbacks or possible complications that this would cause? Or is there a better solution to the problem than this?
Handling Deployment to Multiple Environments
asp.net;deployment
Normally the higher the deployment process is automated, the lower risk there will be. To achieve better automation, i think command line procedures (with different modes, for example, interactive v.s. quiet mode) could be a good option:I believe you won't have many environments (DEV/QA/UAT/PROD/etc.) and they are already fixed. So a fixed xslt transformation could be defined and included in your project, for example, call it web.config.xslt, in which, a list of configuration sections per environment could be defined (or a switch-case conditional configuration)use MSBuild to build the solution, and output the built files to a newwork location (preferably accessible to all developers), and at the end, transform web.config based on web.config.xslt and produce a couple of config files: web.Dev.config, web.QA.config, web.UAT.config and web.Prod.configgive an option at the command line, say which environment the user wants to deploy, then batch copy all the files to the desired server (of course, you have to allow these folders shared and accessible to the deployer) and at the end copy the corresponding web.[ENV].config file as web.config to destination folderother bit and pieces (such as versioning, DLL signing and etc.) could also be included and automated through out the MSBuild process. all these steps could be stored in a predefined solution level file, let's say it mySolution.BuildRelease.proj (all up to you) and set MSbuild (or your self-defined bat file, which calls MSBuild and your own console app) as the default app to open it.of course, if some of the processes could not be done using command line, you might want to try write a console application and call it during MSBuild. if you are fancy with interactive approaches, you may also define a html app (hta) to wrap up the process