Dave Burke : Freelance .NET Web Developer specializing in Online Communities

CS Nuglet: Moving from Development to Production

This is a reprint of a Gold Forums reply on moving Community Server from a development environment to a production environment.  Here's an excerpt of the question.

I was wondering if anybody has come up with a *good* way to move work from a development machine to a production machine?  For instance, I know I shouldn't copy this up to the production server when I have changes for our site, but this bugaboo seems to get me every time. I punch the "Publish..." button in Visual Studio and it happily copies over the production server web.config. Then I thought, why not use the VS2005 Copy Web option? With this option, I could "unselect" the web.config before punching the copy button. Well, that idea quickly seemed bad because a) I don't want to deploy the CS files, and b) I don't want to deploy the junk content I created during testing.  Has anyone come up with a way around these developer headaches?

------------------

This is from my experience doing this a bunch of times...

FTP.  FTP.  FTP.  Don't think about any VS2005 copy or publish options.  You've got a development site.  FTP it to production. 

1) Include the web.config!  Once online, pull it down to a temp directory and update the connection string.  That's all you need to do.

2) ZIP. ZIP. ZIP.  FTPing all of those CS site files is a major pain, so what you want to do is zip up your site by sections, then ftp those zips and unzip them on the server.  You're done.

As for the database, that can be exactly the same as development as well, the only thing you'll want to do is add the site domain to the cs_sites table with

insert into cs_sites values ('myCoolSite.com');

Comments (4) | Post RSS RSS comment feed

Posted on 3/23/2007 8:39:45 AM by Dave Burke
Categories: Community Server
Tags: no tags for this post

Related posts

Comments (4) -

3/23/2007 1:53:13 PM Permalink

Hey Dave, if you are allowed to use the same SQL Server login information for both development and production, there are a couple little tricks that can used so that you don't even have to update the connection strings in your production environment:

1. If using DNS names for your server names and the production environment is using a different DNS server than you do in development then the DNS entries on each DNS servers can point to the appropriate machines.

2. Use client aliases.  For the server name use something like CSSQL.  Then on all of your development and production machines create aliases in the SQL Server Configuration Manager for that name that points to the SQL Server that you want to use.

Take it easy,
Bill

Bill Bosacker |

3/23/2007 2:13:26 PM Permalink

You are one SQL Stud, Bill!  Thanks for the additional tips for those who can use them.  Me, I only know how to use the Restore option. Smile

daveburke |

3/24/2007 7:29:15 PM Permalink

Have you ever thought about creating a deployment script in say, NAnt, and running that from your dev environment?  You can use XMLPoke and other functions to update all the environment specific "stuff" in our configs on deployment.  We do this across the board on projects where I work and it does a pretty good job of it.  You can store the environment settings in a special file that get's read in at deployment time and initializes the values before updating the web.config, and others if need be.

Drew C. |

3/25/2007 7:05:23 AM Permalink

Drew,  Actually I saw a script similar to that after posting this.  I have to investigate the availability of that particular script (it's a .NET EXE actually), but yes, good idea!  Thanks.

daveburke |


Powered by BlogEngine.NET 2.0.0.36
Theme by Dave Burke