Part 2 – This is not a pipe, it’s a pipeline: becoming a DevOps DBA

By Marcus Davage, Lead Product Developer, BMC Software

Last time, I quoted Belgian surrealist artist René Magritte, his ‘This is not a pipe’ painting and his comment that ‘Perception always intercedes between reality and ourselves.’ To bring yourself up to speed, you can read part 1 here

The point I was making was that, when it comes to DevOps and databases, DBAs need to be involved from the outset of project design. Developers (including development DBAs) and operations (including production DBAs) need to collaborate to deliver changes at a pace that satisfies both operational availability and development targets.

The thing is, databases are not the same as applications.

Database changes need to be made before code changes – otherwise your BINDs will fail. There is a much higher risk to database changes: you are affecting user data. Do it wrong, and there’s a serious impact. If there are many development and testing environments, there is a risk of environment Drift, where one or many environments do not get schema changes applied to them. Pre-change Backups and post-failed-change recoveries need to be built, tested, and automated. And many software vendor tools are available to make life easier: schema change management and automated deployment, automatic DML performance analysis, and DDL site standards compliance.

Make a change to code and you affect one application. Make a change to a database and you can potentially affect many other shared systems.

In this world, your DBA is the best person to give you a wider view of system dependency. For far too long, I think, the developer has thrown database requests or poorly performing code over the wall to a DBA, who does his or her best to make it worthy of production, and throw it, along with their database changes, over the wall to operations.

In the final analysis, DevOps is about People, Process, and Tooling. We need a culture change to be able to move at a speed that our customers have begun to expect from us. That culture change extends to the database level. We need to involve the DBA from the very beginning of the development process. And we also need to trust developers to make their own changes, as and when they need to.

What if… in their route-to-live pipeline, developers can implement database changes themselves in a process that includes rules-based validation of the DML (select, update, delete) to ensure company standards and best practice are met, and a similar validation of the DDL (create, alter) to ensure company naming standards and physical database standards are complied with? The DBAs would be in charge of setting those standards, implementing and controlling the rules, and can let developers make their own changes with the knowledge that nothing will break.

So, by letting developers move their own database schema changes around, are we handing over the keys to the kingdom? Does this mean DBAs relinquishing the control they have proudly guarded for generations? Certainly not.

With the right tools, early involvement in the development process, and robust change impact assessments, DBAs still get to keep the keys. They’re merely handing over the automatically enforced, locked standards and orchestration methods that enable developers to get more done themselves, and to do so safely. By defining site standards and SQL performance rules, and embedding them in the orchestration tools and automated migration processes, they are keeping the keys – just handing out locks.

In the world I’m suggesting, database changes are thoroughly impact assessed, and schema change management tools encapsulated in the change orchestration process. DDL are automatically validated against site standards the DBAs have set, and the code’s SQL statements analysed and compared against performance rules defined by the DBA, making sure SQL performance does not degrade. A developer can migrate their own changes through any environment up to, but obviously not including production. The DBA approves production changes and solves any issues or major impacts along the way.

Sounds great, doesn’t it? ‘Perception always intercedes between reality and ourselves’ may well be true. But if we can change our perception of ‘who does what and when’, we can create a new and more effective reality. This is not a pipe, this is a pipeline. This is not a DBA – it’s a DevOps DBA.