How do I easily maintain separate Development and Production versions of project files?

Here's a simple, and I think novel, method I came up with recently to deal with the issue of maintaining a development version of a website, while leaving the working production version intact until changes in development have been tested and are ready for rollout. It involves sharing the files in VSS into two separate projects, one for development and one for production. Changes are made to the development files, and the rollout process is as simple as checking in the changed files, and using "Get Latest" in VSS Explorer to copy the updated files to the web server.

I use InterDev mainly as an ASP editor, so I'm not sure how well (if at all) the method described here will work if you use some of InterDev's more complicated features like remote deployment.

VSS Configuration
[ul][li]Create the development project in VSS.[/li]
[li]The new project will contain the development versions of your web pages, so name it appropriately.[/li]
[li]Optionally, use VSS Admin to mark this project as a web site.[/li]
[li]Share the contents of the existing production project into the new development project.[/li]
[li]Set the working folder of the development project to the location of the web siteÆs development-version content (use a share if the content is on another machine). Create this folder if it doesnÆt already exist. I used a folder named ôdevö under Inetpub on the web server for these files.[/li]
[li]Use ôGet Latest Versionö to fill the development content folder with current versions of the production files.[/li]
[li]If itÆs not already, set the working folder for the production project to be the location of web siteÆs production content, e.g. ôf:\inetpub\wwwrootö if ôfö is mapped to a share of the serverÆs c: drive and production content comes from the default web site content folder.[/li][/ul]

Web Server Configuration
[ul][li]Make a new web site on the server.[/li]
[li]Set it to respond to requests on port 81 (or anything other than 80, which is the default port).[/li]
[li]Configure it to retrieve content from the new folder you made during the VSS configuration.[/li]
[li]Select ôUse Externalö for Version Control on the Server Extensions Tab of the site properties dialog. Specify the new VSS development project as the ôproject to useö.[/li]
[li]All other options (security, etc.) should be the same as for the production site.[/li][/ul]

InterDev
[ul][li]Open the new development site in InterDev[/li]
[li]Connect to, and start a new solution from, the new web site. Be sure to specify (or whichever port you specified in IIS) to make sure youÆre opening the development web site.[/li]
[li]Save the solution, which corresponds to the development version of your site, to your local InterDev documents folder. This new solution will be the one you'll work on in InterDev when making changes to the website.[/li][/ul]

Clean-up
[ul][li]Once you've verified that the new development solution is in place and working, there are some optional steps you can take that might help prevent inadvertent changes to the production website files.[/li]
[li]Delete the production solution. You wonÆt be using InterDev to work directly on the production website anymore, so you can delete the existing local files for the production version of the solution.[/li]
[li]Remove FrontPage Server Extensions from the production website. Again, since you wonÆt be authoring these pages directly anymore, you can use the IIS console to remove the FPSEs from the production website. This could help prevent accidental changes to the production files.[/li][/ul]

Working with the two environments
[ul][li]Making changes in development[/li]
[ul][li]From InterDev, check out the file you need to change.[/li]
[li]Make your changes.[/li]
[li]When you save the file (assuming youÆre working in Master mode), Interdev saves a copy to the development content folder.[/li]
[li]Test the change by pointing your browser to (or whateverÆs appropriate, the important part is to include the port number so that youÆre viewing the development website).[/li][/ul]

[li]Rolling out to production[/li]
[ul][li]When youÆre satisfied that the change(s) youÆve made work, check the file(s) back in to SourceSafe from the InterDev solution explorer.[/li]
[li]Since the file was shared between production & development projects in VSS, checking in also updates the production version (in VSS, not on the web server).[/li]
[li]To update the production-version content files on the server, use ôGet Latest Versionö on the files from within the production project in VSS Explorer. Since the working directory for this project is set to the production content folder on the web server, the get-latest overwrites the production files on the server with the just-checked-in versions.[/li]
[li]The changes youÆve made should now be visible on the production web site. Run some tests on the production site (remove the port number specification in the URL) to verify that everythingÆs working.[/li][/ul][/ul]

Tips
[ul][li]ItÆs a good idea to have a global constants server-side-include file thatÆs included by every page. Branch this file in VSS so that the production and development versions are always different, and use this file to define constants such as:[/li]
[ul][li]Database server (or database) names that should differ between production & development[/li]
[li]A DEV_MODE boolean constant so that every page can know whether itÆs in the production or development environment. This flag can then be used to append ô[DEVELOPMENT]ö to page titles, for example, or change background images to make it obvious when you (or someone else) are looking at the development site.[/li]
[li]DonÆt use this file to define constants that should be identical in production & development, otherwise youÆll have to manually update the two files separately (since theyÆre branched).[/li][/ul]
[li]Even though files arenÆt technically ôrolled outö until you get-latest to the production content folder, donÆt check files in to VSS until youÆre ready to roll out, and when you do check them in, roll them out immediately. This allows you to easily see which files have changes pending in development in VSS Explorer (theyÆre the ones that are checked out). This is especially important if youÆre working with other developers on the same website.[/li][/ul]