Reverse Engineering a DB for DevOps Excellence
Former ThoughtWorker Steve Moyer has written two blog entries on an aspect of an Agile mission we did a few years ago. He was the pivotal designer/implementer of the work.
The first blog entry was Regaining Agility in the Face of Legacy Databases
The second was Working With Legacy Databases: A Case Study
Both are very much worth a read generally, but they should be of particular interest to folks wishing to move control for DB creation to scripts under source-control, so that Continuous Integration can ‘reinforce value’ with each commit of code. Developers can benefit too by separately standing up a microcosm version of the stack, using scripts that took seconds to complete the creation and initial population of a schema. If devs are sharing a single DB now, and you’re using UI tools to modify that outside of source-control, then Steve’s words should be raked over.
OK, so in the case study Steve outlines the process he used. I’ll copy and paste for your convenience:
Phase 1: Generating a baseline schema (One person over a few days)
Phase 2: Generating an initial dataset (One person over ~3-4 Weeks)
Phase 3: Initial browser based testing and continuous integration (Two people over ~1 week)
Phase 4: Extending the team and moving forward (Ongoing effort across multiple distributed teams)
Pramod Sadlage is ThoughtWorks’ veteran database “agilizer” and co-wrote the book Refactoring Databases. It is nice to see more case-studies from the field, that facilitate a nimble usage management of table-shapes going forward.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)