How to properly develop and deploy features for existing asp.net applications on IIS

Question

My question actually consists of multiple questions. I'm frequently reading about companies who deploy a small subset of features for a select amount of customers using the live "database". Ruby on Rails and its ecosystem have deployment tools and database migrations to deploy or rollback such features in a live production or staging environment.

My question, how is this done for an asp.net (mvc in particular) application? How do you test your newly released features against live data? Do you have any tools to modify the existing database and roll back changes if necessary? Do you make backups before deployment?

Update

Maybe I should point out that my question is not really clear, getting more answers here will help me phrase the question better. To make it easier I will describe a situation I'm commonly seeing with some of my clients.

My clients have large deployments of popular web applications. They do not have staging/QA/testing servers. (yes this is not optimal). The data their apps consist of are images, xml files, user uploads and data in Sql Server. Having a few records, of their production database and a couple of dummy files is not a substitute of testing against real data in my opinion. How would you design a workflow that can create a acceptable environment to mimic a production environment before going live?

Another Update

What I'm still wondering is what tools, or procedures can you use to take a realistic snapshot of your production data (files, database) such that you can build your own Q & A environment. The entire database and files relating to that are too large to copy entirely to the Q & A server. But if you just copy the first couple of rows of each table, they might have no relation with each other and give random errors or unexpected behavior all over the place and does not reflect a realistic production database.

PS. If anyone understands what I'm aiming at and has a better way to phrase my question feel free to edit mine!

Answer 1

How do you test your newly released features against the live database?

You don't. You test new features and fixes against a QA version of the database, then promote the code changes and any database schema changes to the production servers once they have been vetted.

Red Gate makes products that are useful for packaging database modifications for promotion and rollback of database schema changes.

UPDATE:

There is really no substitute for a testing environment. You can't perform testing against production, it's just too risky. The best you can do without a dedicated testing environment is model production behavior as accurately as possible in your development environment. Use Virtual Machines to run the server operating system (i.e. Windows Server 2003) and get those VMs configured as closely as possible to the way the production servers are set up.

ANOTHER UPDATE:

You can use diff tools like Filesync to synchronize application files between your QA and Production environments. If you cannot, for some reason, maintain a complete copy of your production database in QA, then use scripts to "carve out" and export data that is complete enough for testing.

I also recommend The Build Master. It's a great reference on configuration management, source control, and build management for software development.

Answer 2

That's interesting question, but you couldn't compare rails with ASP.Net MVC 1:1, because ASP.Net MVC is just a UI-Framework and not a full-stack framework like rails (or grails).

So, the question about the database depends what kind of data access technology you use. If you use NHibernate, there is some support. But with the Microsoft data access technologies (data set, linq2sql, entity framework) I don't know a way to automate things like migrate or downgrade a database schema (with data migration).

Answer 3

QA is the way to go and you have already told that you are aware of it. If at all, having a QA box is not an option, why not have a dummy web site that is exposed only for testing. You can have a close to production database. You can run this dummy website against a copy of the database in a separate application pool and reset the app pool if required without hampering production. Once you are done, delete the database copy and roll up the changes to the actual web site.

NB - This is just a workaround until you get a real QA setup.