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:
- Development
- User Acceptance Testing (UAT)
- Production
The 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
Best Answer
Migrations
An 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:
Well 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.