Kevin - Tony's way of doing it works but there might be a better way too of handling this. In my particular case we didn't have the luxury of being able to take a copy of Production and install our stuff over it and restore back in production. Main reason for this is that our site was a very high volume with users creating accounts on it at any time of the day (Health insurance industry).

The approach we took with this was as follows.

Create 3 environments -
Development (laptops/desktops - whatever the developer works on)
QA (separate environment with it's own QA version of the database)
Staging ( separate environment with a copy of Production's database) - this environment is always a copy of production till a new release is about to be pushed out

Production (real environment with it's own production copy of DNN).

We had the developers create all the code individually on their machines but we used Subversion to manage the code as our source code repository. No developer was expected to check in code that would break the build and we managed this via a Build Master assigned solely to be responsible for stuff in the repository.

One of the things I want to point out here, in our dev environment we were using a gold copy of the DNN database (ie all the functionality we're using but without the users/accounts that were being created in QA/staging or Production).  We also used the source version of DNN because we knew we were going to be making various changes (ie adding new modules, modifying core functionality, etc).
 

Whenever a build was ready to be pushed out, we had the build master basically use VISUAL studio 2005's SQL Compare functionality to compare our Gold copy to QA and generate a sql script that would make any changes to any of the tables. We used Text/HTML extensively so this allowed us to move changes from environment to environment very efficiently. We used an automated process which would then package this script that was generated with the contents of the Website sub folder and this was then checked into the subversion repository as a zip file.
There was a process which would monitor the repository and as soon as a new build was pushed out to the repository, it would be deployed to the QA environment (ie SQL Scripts executed and website folder copied over). We managed the build version by modifying a key in web.config to indicate that a build had been updated.
The QA environment was basically the first environment after dev in which things were tested out by the testing team.  Once the testing team had vetted the build, they would notify the network/operations team that the build was ready to be pushed out. Operations would grab a copy of the production database and push it into the Staging environment and then apply the build exactly the same way as was done in QA. Testers would then confirm this also works at which point Operations would push out the build into production (ie applying the sql scripts and website files)...

One of the things here that helped here is that operations didn't really need to know about DNN at all - all they had to do was execute a sql script (which can be automated too) and copy over the website folder contents. This was key to us as our requirement was to ensure that developers weren't touching staging or production. The other thing here was that it didn't matter that a build had a new module in it, as long as our sql scripts had the right entries in it, we'd be simply pushing out the insert/update scripts as was neccessary. Internally we had one master Gold copy of the database which was managed by the Build Master which ensured that we weren't generating scripts off a developer's machine that might have been testing stuff out...

Now, our environment was like this due to it's size as well as requirements - a DNN team of 12-15 developers with a separate DB team too. We had an overall team size of 100+ people so to us it was important to create an efficient process which I believe we did accomplish.
I can provide more details if neccessary

Thanks

Sanjay

Kevin - Let me try and address your questions in parts

a) with regards to read/write access to files - we used Subversion (with TortoiseSVN as the Windows piece) which doesn't have the read only type of mode which VSS uses. As such we didn't really run into the problem of read only files in our environment. I'm not really sure of a good way to overcome this unless maybe you can designate a build master who before he/she creates a build checks out all the files first from the repository. Maybe someone else in this community could address this issue better :(

b) Uploading file through the UI - we ran into this in our project and basically again our process of managing this via the build master would ensure that this was taken care of. I was also the lead architect on the project and typically any requests like this would have to get channeled through me which would result in ensuring that the right references were made in Visual Studio before the sln files were checked in (either by me or another developer). Not sure if this is the best approach but we were able to accomplish nearly 99% success with builds with the controlled procedure we had in place.  In your specific case is there a reason you're doing this through the UI besides just the convienence factor? In our specific case, we had thousands of invoice pdfs which were associated with a user but we ended up using a naming convention with the files and based on the user logged in, we'd transverse a folder structure to determine which files to display to the user. On the development environments we didn't copy over the entire list of invoices but instead just a couple to test out our functionality.

c) dll issues - In our environment we did NOT check in the module dlls for any of our modules (most of the bin folder) and instead had the developers download the files from the repository and build on their machines.  Our solution file had all the module projects built into the main project and we used Postbuild tasks to push out the dlls into the bin folder (of DNN) after the build was successful. When we were ready to push a build out, I had a NANT script which was configured to go through each of the neccessary projects/modules and build the dlls in release mode which was then copied into the bin folder automatically before the entire website folder was zipped up. We did create modules from time to time and the way we handled the installation on other developer machines would be to use the sql script to basically push the module definition (like we did with the normal build). Once the gold copy of the database was updated, developers could either use the SQL script to bring their copies up to date with the new module definition or they could refresh their copy with the gold copy of the database..

d)Having developers use a local copy - not sure of the context of this question. If it's with regards to the dlls then I think I've addressed that - if it's with regards to the database then that would require some thinking about. Again, in our environment we had a distributed team - developers in Phoenix, Dallas and Manila so we didn't have the option of not using a local copy of the db...  I think even in a single location environment I would recommend using local copies of databases which allows your developers to work on pieces of the puzzle without constraining them to wait for other developers etc.

Hope this helps :).

Sanjay