For the last few years Microsoft and others have been promoting declarative, model-based database development. For many this is the way forward – design the desired state and let software work out the upgrades. Gone are the days of managing endless upgrade scripts and manual deployments.
At the same time, leaders and shakers of our industry including Jez Humble, Pramod Sadalge and Paul Stovell promote an iterative, migration script driven approach asserting that deployment scripts should be tested early and not generated by software. They often assert that a disciplines migrations approach is the only reliable way to achieve database continuous delivery.
So many presenters have opinions that one of the approaches is the “right” way and the other is the “wrong” way. However, like with most complicated problems, the truth is that it depends.
I’ll illustrate the relative strengths and limitations of each approach with a simple scenario. I’ll describe teams and databases that are better suited to a model or a migrations approach, and whether it’s possible to get the best of both worlds.
You’ll leave this session with a better understanding of what options are available to you and which is more likely to work for your team. With so many teams struggling to apply continuous delivery to their databases it’s important to consider whether the problems you are facing are because you have taken an approach which is fundamentally unsuitable for your database.