All too often, database development is an afterthought in Agile Development.
Developers perfect how best to implement a solution in code, but tend to
spend too little time on representing that solution in the Database. This
is unfortunate, given that 65% of your change requests require changes to the
application schema, according to independent research conducted by Simon
Management Group. This finding implies that Database changes are every bit
as important as the Application Code, and should be treated as tier-one
artifacts in your release process.
At Datical, we typically find that development organizations process Database
changes in one of two ways:
Developers author Database changes, which must then be reviewed and approved
by the DBA team, or Developers submit Database change requests to the DBA
team, who then author changes.
Either scenario would work fi... (more)
In my first post in this series, I discussed the underpinning principles of
all DevOps patterns as eloquently stated by Gene Kim, author of "The Phoenix
Project." In this post I'd like to dig a little deeper into The First
Way. As a refresher:
The First Way: Systems Thinking - This Way stresses the performance of the
entire system of value delivery. Instead of becoming laser focused on the
part of the process for which an individual or team is responsible, the
individual or team works to understand the entire process from requirements
generation to customer delivery. The goa... (more)
Recently, the Agile Austin DevOps SIG invited Datical to talk about the
impact of DevOps practices on database change management. This was a great
opportunity for us to talk to folks about our approach to managing
application schema change in IT organizations that have moved or are moving
to more responsive and agile planning, development, and delivery processes.
It was a lively discussion with some great feedback from the audience.
In framing the discussion, I relied heavily on "The Three Ways" of DevOps.
The Three Ways are the principles that underpin the DevOps patterns that... (more)
In the third post in this series, I’d like to talk about the Second Way of
DevOps: Amplifying Feedback Loops. Here’s a refresher on The Second Way
from my introductory post in this series:
The Second Way: Amplify Feedback Loops – This Way deals primarily with
facilitating easier and faster communication between all individuals in a
DevOps organization. The goals of this step are to foster better
understanding of all internal and external customers in the process and to
develop an accessible body of knowledge to replace the dependence on
expertise scattered across individuals.
The vast majority of schema management today is handled through the
generation, review, and execution of SQL scripts. These scripts can be tiny
or huge; they can encapsulate the creation and relationships of several
objects or they can describe a one-time alteration to a single object. Once
executed they generally leave no history of their passing other than the
presence of the pieces they create, delete or modify; you can be dependent on
hundreds of small scripts or on one giant script to build out new
environments or evaluate existing ones. You’re left with a schema that is ... (more)