Best practice when moving web.config from test to production server
Hi all
I'd like to know what you think is the best practice when moving the web.config from a test/staging environment to a production environment. Since I started with Umbraco I have been involved in several solutions, and every time I bump into this "problem", because the content of the web.config is never the same on the test server and on the production server. Of course the biggest part of the file is usually identical, but there will however always be some differences. E.g. the DB connection string.
Right now I'm working on a big project where the connection string is just a part of the differences in the web.config, so right now I'd like to know how you guys control this procedure. Do you use some kind of merging-tool? Or are you just making the changes manually on both the test server and the production server?
I know that we're not going to change the content of the web.config every day, but I hope that you guys have some good inputs to this.
Ah, I think the guys at the FARM have done an article on their deployment setup, including issues such as different db conn stings etc... Let me dig that up...
Maybe be bit overkill in your situation, but you might get inspired by them...
I typically handle this scenario in my procedures of releasing my project in my SourceControl environment (Subversion,SVN) And this approach is not my idea - it's taking from some howtos, tutorials from the Subversion community.
When my project is ready for a release I branch my trunk to a release-branch (RB):
/trunk -> /branches/RB-myproject-v20100525-01
Now inside my branch i make it ready for production:
Change configuration
Create a binary release
Collection my Configuration and binary release in /branches/RB-myproject-v20100525-01/Publish folder
Write Changelog
When my branch RB-myproject-v20100525-01 is ready for final release I tag it in SVN into my /tags structure
Now I can get my final production ready release from my source control repository /tags/REL-myproject-v20100525-01/Publish where I have collected the binary output along with some configuration and changelog info.
What we usually do (when solutions aren't up and running on our build server) is to keep the web.config itself trimmed to a minimum meaning that the appsettings, connectionstrings, role, membership and smtp sections are individual .config-files (or simply the sections that differ between dev, staging and production). i.e.:
In this scenario you would have one web.config, 2 or 3 appsettings.config files (i.e. appsettings.config.dev, appsettings.config.stage, appsettings.config.prod), the same for connectionstrings.config (.dev, .stage, .prod) etc. etc. This should make it pretty simple to create a build script, maybe just a post build in your VS solution that outputs release folders for staging and production.
But if you are up for the challenge you should definiately look into setting up build servers to handle these builds for you (as described by Shannon on the FARMs blog). When you have tried both the simply approach, which I outlined above (you'll have to copy the files to the different servers yourself) and the automatic builds then you will see the power of having a build server and simply being able to deploy your code to staging with a click of a button ;)
Best practice when moving web.config from test to production server
Hi all
I'd like to know what you think is the best practice when moving the web.config from a test/staging environment to a production environment. Since I started with Umbraco I have been involved in several solutions, and every time I bump into this "problem", because the content of the web.config is never the same on the test server and on the production server. Of course the biggest part of the file is usually identical, but there will however always be some differences. E.g. the DB connection string.
Right now I'm working on a big project where the connection string is just a part of the differences in the web.config, so right now I'd like to know how you guys control this procedure. Do you use some kind of merging-tool? Or are you just making the changes manually on both the test server and the production server?
I know that we're not going to change the content of the web.config every day, but I hope that you guys have some good inputs to this.
Looking forward to hearing from all of you :)
/Kim A
Ah, I think the guys at the FARM have done an article on their deployment setup, including issues such as different db conn stings etc... Let me dig that up...
Maybe be bit overkill in your situation, but you might get inspired by them...
Cheers,
/Dirk
Hi Kim
I typically handle this scenario in my procedures of releasing my project in my SourceControl environment (Subversion,SVN)
And this approach is not my idea - it's taking from some howtos, tutorials from the Subversion community.
When my project is ready for a release I branch my trunk to a release-branch (RB):
Now inside my branch i make it ready for production:
@Dirk:
Thanks for the link Dirk. I'll check it out for sure!
@Kevin:
I never thought of this way actually. Interesting stuff. Thanks for your input :)
/Kim A
If your project is edited in VS 2010, I would look into VS 2010 handling of this problem, seems like at good solution.
Regards
Jesper Hauge
Hi Kim,
What we usually do (when solutions aren't up and running on our build server) is to keep the web.config itself trimmed to a minimum meaning that the appsettings, connectionstrings, role, membership and smtp sections are individual .config-files (or simply the sections that differ between dev, staging and production).
i.e.:
In this scenario you would have one web.config, 2 or 3 appsettings.config files (i.e. appsettings.config.dev, appsettings.config.stage, appsettings.config.prod), the same for connectionstrings.config (.dev, .stage, .prod) etc. etc.
This should make it pretty simple to create a build script, maybe just a post build in your VS solution that outputs release folders for staging and production.
But if you are up for the challenge you should definiately look into setting up build servers to handle these builds for you (as described by Shannon on the FARMs blog). When you have tried both the simply approach, which I outlined above (you'll have to copy the files to the different servers yourself) and the automatic builds then you will see the power of having a build server and simply being able to deploy your code to staging with a click of a button ;)
Hope this gives you some inspiration.
- Morten
We actually use MSBuild not Nant any more - http://www.farmcode.org/post/2009/10/02/2-Click-ASPNET-Web-Application-Deployment-with-MSBuild.aspx
is working on a reply...
This forum is in read-only mode while we transition to the new forum.
You can continue this topic on the new forum by tapping the "Continue discussion" link below.