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!
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With