For the last two months or so I have been looking for solutions or practices to handle release management within databases.  I'm looking for what people view as the best process for handling this.We have 3 environments for our databases:DevelopmentUser Acceptance Testing (UAT)ProductionThe problem is sometimes we are making changes to several things within our development database and come time to deploy, some of the features may not be ready to be released to UAT.Recently we have started using Red Gate SQL Source control for storing all of our entities (with regular commits).I was thinking of going based off of changesets (i.e. say everything from changeset X and back is now being pushed to UAT) however, this means that people are only checking their code into source control just before we do a deploy which can get confusing (especially since people are forgetful).  Another issue with going with the changeset approach is if there is a bug in a stored procedure that needs to be fixed, the changeset number would end up being out of scope of our max changeset for the revision therefore making it so that if we need to recreate the database off of a maximum changeset, we would be pushing the bug out again.Any suggestions on a process?Thanks
How do you handle constantly changing database dimensions?
database;sql;sql server;tsql
MigrationsAn up and a down, that are in your repo and tagged along with your app.You can even DIY with sql flatfiles that modify your schema and update the schema version.  All you really have to do is:keep your migrations next to the source code, they should be versioned and tagged togetheralways use managed changes (migrations) in all environmentsnever allow ad-hoc modifications in any environmentsWell you can do development changes in dev, but you should always blow away you db and rebuild it with migrations once you've captured the change.