- On the basic idea of building a database in an agile manner
- On how you might start putting together a version controlled database build script
- On how you can organise patches to reduce the pain of a rolling back changes
- On the arguments between table-centric and patch-centric database build scripts
- On what automated build scripts give you
- On having the build script be able to tell when something goes wrong, and stop
- On how you can use your automated builds to give you a sandbox
- On why your DBAs shouldn't burst into tears when you tell them you need a database for each developer
- On how you database build script can work with you version control tool
- As well as: a presentation given to the UK OUG
Tuesday, September 04, 2007
Database Build Script "Greatest Hits"
I know its been a quiet time on this blog for a while now, but I've noticed that I'm still getting visitors looking up old blog posts. It's especially true of the posts that relate to "The Patch Runner". Many of them come through a link from Wilfred van der Deijl, mainly his great post of "Version control of Database Objects".
The patch runner is my grand idea for a version controlled database build script that you can use to give your developers sandbox databases to play with as well as ensuring that your live database upgrades work first time, every time.
It's all still working perfectly here, and people still seem to be interested, so with that in mind I've decided to collate them a little bit. basically provide an index of all the posts I've made over the years that directly relate to database build scripts, sandboxes and version control.
So, Rob's database build script 'Greatest Hits':
Subscribe to:
Post Comments (Atom)
4 comments:
Great series of articles, This is something that I would really love to get going, and have started to play around with, fashioning my solution (which is just in my head) in a ruby-migrate kind of way. I fear its all going to get very complex very quickly though.
If you view the build script / patch runner the same way as you would view any other piece of code, sit down and think about it, refactor it mercilessly and only accept solid, lean, modularised, working code then you'll probably find it's a lot less complex than you might imagine.
Try not to be too generic, just implement what you need in your environment (at least to start with).
Go on, try it.
Hmmm, seems cool.
Joe joestain13@yahoo.com
So many moons on and still so relevant!
I produced a patcher for the python framework Django, it gained some interest and IBM used it as the basis for their patch system in their ProjectZero framework.
Great to know how things work out, isn't it?
Post a Comment