How to propagate data changes between dev, qa, and production

release-management

I have tools for propagating database definition changes, but any data changes I make I write scripts for and run them in each environment by hand.

There are some data changes/additions that have to be made routinely and I would like to create a GUI for handling this, but if I did that then I no longer have the sql scripts to run in other environments (unless I generate them from the GUI tool, but then I'm still left having to run those changes by hand in other environments).

One idea I'm mulling over is to write the GUI tool in such a way that it generates the xml files for objects I've added or changed and include these xml files in the publication of the web project. Then the application can look at these xml files and update the database accordingly.

Are there any standard practices or tools for pushing data changes automatically along with your db definition and/or code changes?

EDIT:

Based off the first answer I received it appears like I might have made it sound as though I want a tool to compare dev databases to production databases and propagate all changes. This is DEFINITELY NOT what I was trying to communicate.

One example of what I'm dealing with is language texts that have to be added (no, I can't use resource files for this because end users can modify the texts through the application at runtime). Instead of having to hand write scripts every time I need to add texts for a new item, it would be great if I could just create a GUI tool to simplify the process.

I think it's pretty obvious why I would prefer to use a GUI over hand writing SQL statements, and so the next question is why would I want to propagate this the same way we propagate code changes. Well, this isn't like other test data. This is data that will ALWAYS be propagated to each environment. The same sort of concerns that lead us to use tools to simplify the process of pushing code or database changes to each environment apply to the kind of data I'm talking about here.

Best Answer

Why would you want to propagate changes to the data along with the promotion of definition or code changes from Dev to QA to Prod?

I wouldn't think there is something like that out there because if anything, it is better to be able to refresh Dev and QA with data from Prod...not the other way around. In a situation where you need to create new data in Dev or QA because you are testing a new function that deals with something existing data doesn't contain, the thing is it is just that...TEST data. QA best practices dictate the data going in Prod must be clean.

If you must, best practices in my experience are what you have already - use scripts (there are some data migration tools out there that are meant for such a thing), or put them in manually.