When it was standard practice to release one application once a quarter, it made perfect to sense to have a DBA manually review the SQL script to make changes in production. Given the importance of the database, that was more than reasonable.
Now, thanks to Agile, there are hundreds of applications that release every two weeks. That means the same DBA is performing 150+ releases a quarter. There is no way that individual can catch every standards violation that puts data at risk. It’s time to stop pretending that they can and fix this pitfall.
Let’s be honest and engage in some simple problem-solving. Since the reliance on time-worn database deployment processes and tools is not working, it’s time to engage with the teams requesting and initiating the change. DBAs must take the initiative to adapt their interactions with developers to improve processes and tools. They might even need to choose new processes and tools (gasp!) to support how they build software.
Working software over comprehensive documentation
Before Agile was all the rage, there was a time when RTFM was the catch-all response to “How do I…?” That is not acceptable today. After all, Facebook doesn’t provide a manual for its product so that’s the reality we must live with, like it or not.
The working software we produce should guide users to the happy path. When users veer off that path, there must be an elegant and yet simple method to returning them to productivity. The same must be done for the database.
Unfortunately, this is easier said than done. At some point, it will be necessary to document and enforce how database schema updates are pushed from one environment to the next. My recommendation would be to update the new repository template for the source code control system. When a new repository is requested, include some examples of how database updates should be in source code control. Right alongside the “src” and “test” directories, I’d love to see “db.”
Customer collaboration over contract negotiation
Debating process over results will never fix a problem. Database administrators must realize their customer is the application developer and the business. DBAs serve two masters; they must support the needs of the Agile dev team during releases while making certain the data is safe.
These may seem like conflicting goals (probably because they can be), but that’s the constant paradox DBAs live in. If a SQL script does not pass standards and the DBA team rejects it, that is everyone’s problem, not just application development’s. We no longer live in a “not my department” type of world.
Responding to change over following a plan
Sign up for CIO Asia eNewsletters.