Hi,

I've been searching & frustrated for the better part of today - in doing what should be a fairly straightforward development process: Deploying my dev DNN site on my development box to a staging and a production server.

Here is what I am trying to achieve:

1. Set up DNN 4.8.4 on my dev machine (W2003 server, SQL Server 2005 std, VS 2005)
2. Set up DNN 4.8.4 on my staging server (W2003 server, SQL Server 2005 std)
3. Set up DNN 4.8.4 on my production server (W2003 server, SQL Server 2005 std)

I feel that this is a fairly NORMAL development setup, at least for me and any software company that I've ever worked for.  The idea is that I develop on the (ahem) development machine, when a build is ready, deploy it to the staging server (which has an identical environment to the production server), put the build through testing and when it passes, deploy to the live server.  This is a NORMAL way to develop to me... development should not, except in emergencies, be done on the production environment.

First, kudos to whomever is responsible for the install application - it worked perfectly the four or five times I've used it on my dev box.  Logical and efficient.

Now you will notice that the 3 environments that I have are all quite similar, in a vain hope to eliminate as many 'environemental difference' problems as possible.

There doesn't seem to be any f0rmal instructions for how to accomplish deployment from dev to staging or production.  In the forum I find some posts that seem to think it's a bad idea to deploy.  That you should package up your individual enhancements into modules so that you can, instead of deploying, sort of 'upgrade' the staging and production installs with your custom modules.  Some posts recommend developing on the production server so that you don't have to deploy.

Now, in my hours of searching have I missed some documentation that outlines how to deploy?  Ideally is there some sort of wizard that you can use from the site or host admin?  I'm not holding my breath but the DNN framework is sometimes quite amazing with great features.  Maybe I've missed that one.

If DNN doesn't have it, why not?  I can see a need for users to be able to deploy individual portals, as well as the entire 'host'.

In any case, here is what I did to deploy to staging.  It's probably quite a bodge, and I'm sure that there is an easier way to do it....

1. Set up development environment using a SOURCE install.
2. Install SOURCE modules for modules that you are going to want to view the code of, or hack around a bit.
3. Set up your portal.  Create pages.  Develop custom modules.  Alter existing modules to suit.  Build a skin.  etc
4. Copy the contents of the 'website' directory (from the SOURCE DNN install) up to the production server, where you want it to eventually live.  I usually use FTP to do this, (and a fantastic little tool: BeyondCompare - it's a developer 'must have' Diff tool).
5. On the staging server, set up a website in IIS as per the instructions in the official DNN install .pdf
6. Use SQL Server Management Studio to do a backup of your dev DB.
7. copy the DB dump (backup) to the staging server.
8. Use SQL Server Management Studio to 'restore' the dev DB into your Staging DB.
9. Manualy add a new portal alias by entering  new record in the PortalAlias table on the Staging DB.

And that's pretty much it. Except today I had the default portal come up and running fine, but the other portals didn't work, I kept getting the dreaded 'Under Construction' page when trying to browse to them. After mucho swearing I figured out that I could just go into IIS and add the alias' of the non-working portals to the 'host header' for the DNN website. I don't understand how DNN works it's magic, but I assume it's some sort of ISAPI binding mojo that intercepts incoming requests, and if there isn't a host-header match in IIS, looks into the DNN portal alias table and redirects.

Now that I have my dev and staging sites up and running, I don't have any problem modding files in dev and FTPing them up to the staging server. Any DB changes are a different thing: does anyone have a list of tables and even better, a script or module that allows updating the DNN from one DB to another? I'm thinking about cooking something up, but I'm sure to be missing stuff - and that will engender the dreaded DNN 'rot'!

summary

So, I just want to know the 'approved' deployment method to move code AND DB changes from one DNN install to another. Note point 3 above - I've hacked some of the standard code to get it to work the way that we need, most of the hacks would NOT lend themselves well to putting in modules, as they effect the core code.

Cheers, Lance

The way that works for me is to:

• Have the 3 environments
• Create the module in dev and export it as a module package
• Copy the entire DNN site in production to the Staging environment and then upload the module to it and test it
• Install the module in production

At my job we attach the actual Module to the "Change Request" in Team Foundation Server. Nothing gets lost. Rolling chages back is easy. The server admins install the exact smae module in Staging as they do in production so there are no surprises. I'm a careful programmer but 10% of my change requests get bounced and never "foul up production".

Well for any small potatoes guys/girls out there that can't afford 3 servers and may be developing sites for small businesses,  you can accomplish most of this with  2 machines, one for development and one for production that sort of also doubles as a staging enviroment.  I develop sites and modules on my XP Pro machine with VS 2005/2008 and SQL Express.  I  backup the db and zip up the entire installation and move the files to my server, a Win 2003 with SLQ Express. I unzip into a new directory on the server, use Studio Management Express to restore the db, adjust the portal alias, configure IIS, and the site goes live.  Now I create a new empty db in Studio Management Express, name it testsite, and restore this database with the same backup by choosing the overwrite option.  I then make a new directory for the test site and unzip my files into this directory also.  I them make the appropriate changes to the portal alias table, set up IIS for the test site and the site comes up.  So now I have 3 installs of the same site, one on my dev machine and 2 on my server. 

I know this is not optimal but so far it has proved a productive way to work. I can test all changes made in development to my test site and when satisified that this site is working properly, I can then stop the live site, make adjustments to my test sites portal alias table, adjust my IIS host header records, and now my test site is my production site and my previous production site is now my test site.