Embracing Database DevOPs

What is Database DevOPs and why is it important?

I have been asked many times at conferences and in general conversations about the role of a traditional DBA and that role being phased out. I ask, why do you think this is the case? And their answers:

• “The introduction of the cloud will take care of everything for us”
• “The enhancements being made in automating SQL Server environments means we no longer need a DBA”
• “Self Service BI allows us to more quickly achieve our reporting requirements”

Now i do agree that the introduction of all of these statements/concerns does change things however, they do not eliminate the need for a DBA. But with the rate of change that is being experienced how can you as a DBA keep up? This brings me to the point of this post. Change and Growth.

Change – “If we are not willing to change what we do and how we do it over the course of our career do we have a career or are we like Ground Hog Day? Do, Rinse, Repeat”

Growth – “In my opinion, an individual’s willingness to grow allows them to accept change and learn new things and approach things in different lights based on situations”

Your SQL Server database is more than just a storage bucket to hold your important data. Over the last couple of years, the amounts and types of data that are available is exploding and being able to keep up with ensuring the integrity, availability and performance of that data is hard, but simplifying database updates can be made easier.

We all know traditionally most database changes have to be undertaken out of hours so as to not impact the business. But what about the impact that has on staff? Late nights, weekends away from family and friends. Secondly what most people do not think about is the impact that humans make on implementations/deployments, we are human and are prone to mistakes or inconsistencies. Case in point, a SQL Server build process that relies on a fully manual process is not just time consuming, but open to misinterpretation and inconsistencies with the builds that down the track can have issues bubble up to the surface over time. An automated solution of pre-configured builds provide a consistent and reliable solution each and every time and you can ensure the outcome is as required. By automating the build process, does that mean you are doing yourself out of a job? No, in fact you are able to spend more time on things that are more beneficial to the business and you can sleep well at night knowing all of the builds are consistent.

SQL Masters Consulting, a traditional Database Management consultancy, is now incorporating Database DevOPs to assist clients with trying to keep pace with this ever increasing velocity of change as this is not in any way an indication that the role of a DBA is not necessary. By encompassing Database DevOPs and assisting clients with Database DevOPs, it allows for the DBA to focus more on the requirements of the business than the time consuming activities that are able to be taken care of with Database DevOPs providing a consistent, repeatable and reliable continuous delivery of change to the database environment.

Over the past 20 years working as a database professional, the concept of Database DevOPs has always been around, however the ability to automate tasks has not been as simple for the database as it has been for application development. But the principles of Application Lifecycle Management (ALM) are applicable to Database DevOPs and given the advances over the last 20 years with various database tools the benefits that are achievable by including DevOPs for the database are being realised by many organisations to achieve greater operation efficiency.

Database DevOPs just like ALM utilises these principles:

Source Control – The storing of all database code, from initial schema creation scripts to each iterative modification allows for a known good state of a database in a particular environment at a particular point in time. This allows for many different database professionals (Developers & DBA’s) to be confident in the state of play of what is happening in the database environment. Some data can even be stored but that is a completely different discussion.

Unit Testing – All changes that are being created and deployed require tests to verify the change being made does meet the requirements and does not break or cause issues to the deployed environment. Tests should not be an afterthought of a change but in fact they should drive the change based on the change requirements.

Repeatable Deployments – The process of being able to deploy small changes using the same process over and over again and achieving the same outcome.

Continuous Delivery – The process of taking a change and being able to apply it through the various environments, utilising the unit tests mentioned above to ensure the change is acceptable to be applied to the next environment culminating in being deployed to production. This for the most part is automated, however this also can require some human intervention for approvals and verifications. Under no circumstances should changes be made directly into an environment.

Seeing the efficiencies of practicing it, I have become an advocate of Database DevOPs and I do believe that by embracing Database DevOPs this can bolster and improve your ability as a DBA, by being able to keep pace with the rate of change and not get bogged down in time consuming activities and be able to provide greater benefits for your employer.