Best practices for continuous development and deployment of

I've been reading a few related forum posts on this, but I haven't quite found a satisfactory answer.  I'm interested in hearing what might be some best practices for managing, developing, and deploying customizations for Sitefinity 5.x for EXISTING sites.

In my case, we have our own dedicated web servers (so, it's NOT shared hosting), so we have full access to IIS, file system, databases, etc.  When we released our 5.3 site, we pretty much copied the whole development folder, including source code and compiled binaries, backed up and restored the SQL database onto production SQL server, and ensured all configurations were updated accordingly.

While that approach worked fine in the end, it wasn't really very clean.  The production site now has includes all .cs and .designer files, which aren't really serving any good there, and they're just cluttering things up.  There are also various Sitefinity migration packages in the root ("Module3.7_xx_xxx.zip") which I assume are to do with the Migration Tool?  Makes me wonder if they should really be preserved in a production site, once it's gone live (and after you've presumably already done a migration from 3.7, if any).

On the Visual Studio 2010 side, there is "Publish Profiles" functionality and ability to configure one-click publishing to the production server through a file system network path.  But doing so might overwrite necessary things, if one is not careful.  But the nice thing about this form of publishing is that it would strip out all source code files and leave only what's needed to actually RUN the finished site.  Or is it not advised to deploy the package directly to production?  If so, how then?

So... All these things in mind, what are some of the best practices out there for managing a clean production site, plus a separate development site, with ability to move things into production QUICKLY and EASILY?

This is definitely one of those, 'depends' answers. So taking into account that what I do may not suit others.

I use TFS

I have one Root TFS project with a folder of all the dlls for each release.
Then a folder for each website.
I also have a folder named Shared for shared modules.

Each web solution references the appropriate release folder of dlls,
The configuration folder is excluded from the project, as well as the bin folder.
I use web deploy to publish to different environments.
     I select to not delete extra files on the server. (I don't want the configs or File Storage files deleted.)
     I use web transforms to do any particular environment changes if required.

With that setup, to update a site requires me to Right click and publish to the environment of choice. (After backups of course)

Shared modules. Each new release of Sitefinity, I branch each of my shared modules and then have them reference  the appropriate release dlls'. The web projects are updated when I update that project. That way I don't have to update every site at the same time. I can do it as required.

This works pretty well for me. Last weekend I updated 5 sites in production within three hours and most of that time was spent drinking coffee watching files upload. (That was after updating them locally and testing first.)

Sure there are a few extra details which I am not thinking of right now. But hopefully the above is helpful.

Thanks.  That's helpful.  I don't use TFS, but SourceGear Vault instead (for basic source code version control).  I don't really use it for deployment, so I rely more on VS2010 for that.

Still, it's helpful to see what others are doing.  I was also thinking that I would not allow the Publish feature to delete extra files on server.  It's just too dangerous.  But it does make me wonder even about the main web.config. for instance.  Since IIS changes can put things into web.config nowadays, how do you ensure that your web deploy/publish process doesn't blow away any added IIS settings on web server?

Yes you are right. Always make sure not to delete extra files on the server. Before every publish I check this checkbox religiously.

On that I always avoid extra static files where possible in my projects. If I create modules for SF I include css, images and js files as embedded resources. I keep the SF project as clean as possible. That way I don't end up with excess files due to the publish.

I assume you mean you can go through the IIS manager GUI and make changes there such as app setting values or url rules.

I haven't tested what happens but I would recommended you don't mix the two. I always make changes to the  project and then deploy.

If you make changes directly to the web config via the IIS management tool. You instantly make those changes to the project web config. So next deploy has them.

I run into a lot of others "weirdness" because they have a random policy of web config maintenance.