Why Do We Talk About DevOps Like It’s a New Concept?

Margi Murphy brings up a great question in an article for Computer Weekly: Agile has been around since the early nineties and DevOps has also been around for a number of years. These concepts have been proven and have seemingly been adopted by a majority of organizations, so why are we still speaking of DevOps and Agile as if they are new?

Murphy posed this question to CA Technologies chief product officer Aymen Sayed who said that despite the considerable ink spilled on this subject, major companies are still not getting it right when it comes to DevOps and Agile, for that reason, they ARE relatively new concepts. Executives have adopted Agile and DevOps in theory but face a challenge with sticking to it throughout the software life cycle from idea to the point of delivery.

This is a very important point, and when we talk about sticking with DevOps all the way through, I believe the main area which is being overlooked is the database.

Databases hold the most vital company information and they need to start being treated like they matter as much, if not more, that the code being written for a company’s software. So, the question is, how do we close that gap between source code automation and database automation?

The answer is simpler than you might think. We need to bring the same processes for source code continuous delivery to DevOps for the Database. What a novel concept!

DevOps for Database requires best practices just like source code. Deployment practices need to be enforced. Version control needs to be enforced. Safe automation processes need to be created. You need to include the database in the continuous process and feedback loops. The most important thing is to make sure you have a way to control these processes, and if something needs to be handled there will be automated notifications and red flags to point out the issue.

That being said, ensuring safe continuous delivery of databases is not so simple. Databases are not a collection of files; they hold client information, transaction data, application content, etc. To make automation really work there needs to be a solid transition code created to handle database schema structure, database code, and content such as metadata.

Furthermore, there are organizational-level changes that will be required in order to ensure proper database continuous delivery. Both DBAa and C-level management will be required to adopt these development methods for databases. It can’t be and isn’t a one-person job. Both sides need to advocate for database automation.

Everyone recognizes the importance of the database to the organization. That is the reason DBAs are so afraid to automate and management is not forcing it. It should be just the opposite! Their sentiments on database control and automation need to be more positive. The question they are asking is – what could go wrong if we bring continuous delivery to our database? The question should be – what could go wrong if we don’t bring continuous delivery to our database?

Who’s doing DevOps for the Database? Check out this fantastic InfoGraphic.

Yes, database deployment automation is not a simple process, but the fact is that ensuring continuous delivery means increased productivity, faster time to market, reduced risk for new releases, and higher quality with fewer bugs. Otherwise, your database will keep lagging and eventually you can find yourself in a difficult situation down the road.

DevOps is a continual process, and businesses will experience challenges specific to their company culture. It’s one of the most drawn out trends in IT, but with Gartner’s prediction that 2016 will be the year of Agile, prepare to hear about it a lot more.