With the transition of modern day software development to an agile methodology and more importantly more and more organizations adopting this approach, the implication to the Database Administrator is to be a key active participant in the agile development teams. DBAs are under constant pressure from development teams to make changes to the schema, optimize performance and keep up with quality benchmarks.
DBAs need to adopt certain methodologies which will enable them to do so.
The value of database blueprints
We at Cintra have long lived and breathed the ethos of delivering via a blueprint, rather than reinventing the wheel every deployment. Blueprints allow us to record lessons learned from previous projects, using that knowledge to more rapidly deploy proven architectures and ensuring a risk-free and successful implementation every time.
In the case of an agile project delivery, an effective way handle deltas to the database design under constant agile changes (for example after a sprint or a code drop cycle) is to define a class of the database. Classes, as in the object-oriented world, have total control over the design of their objects. A class is a blueprint which can be instantiated (or in DB terminology duplicated) at will. Hence the DBAs can start focusing on a single, concentrated definition of a database. This approach allows us to confirm changes to the database design after agile cycles to a centralized class. The instantiated databases can be refreshed again from this class thus preparing them for the next agile cycle.
Maintaining modification logs for changes to the database class
Incremental changes after each code drop to the database class should be well documented. This will allow the DBAs to focus on a specific point in time to identify an issue or bug found during the later stages of the testing cycles of code development. To filter out a bug, every database can then be built or upgraded along the exact same transformational path by simply applying the code delta in the correct order after removing or fixing the introduced bug.
Encapsulating database behavior
Applying development agility to databases demands an object-oriented and test-driven approach. A database is an object and its design (the combined logical and physical model) is its class. A good class implementation for the database is to hide the majority of its tables from unauthorized user access and to expose access only through stored procedures and views, essentially creating encapsulated modules of data for specific user groups. DBAs should write routines to hide the implementation details, giving them more freedom to change its internal design.
Unit testing the database design.
Unit testing results derived from the Test document will reveal any unintentionally negatively-impacted system behavior.
This is a critical phase of paramount importance after every agile cycle. The cost of fixing a bug is proportional to when the defect is introduced and when it is found. If the defect is introduced in the current cycle, the repairs are easy or trivial to make. If it’s been realized after a few agile cycles, the repairs are more significant and will affect multiple code drop cycles.
Furthermore, with a test created for every business scenario of your database design, you can keep your class of databases in full working order and, therefore, releasable at all times. Keeping your databases functional and bug-free at all times is essential to supporting an agile development. In fact, it is in effect the very definition of one.
Written by Vaibhav Tyagi – Lead Oracle DBA, Cintra India, October 2015