I recently came across a thought provoking article on Computer Weekly, written by tech journalist Margi Murphy. The article poses a very simple question that really we should all be asking: while agile has been around since the early nineties, today, even DevOps in it’s most modern permutation has been around for almost a decade – so why do we still relate to it as though it’s a new concept.
The concept of digital agility, and more specifically DevOps, has already been adopted by a seeming majority of organizations, so why is it still afforded the next-gen, cutting-edge treatment?
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 a well-structured and properly implemented program for digital agility. Therefore, he argues, regardless of chronology, effectively DevOps remains a new concept.
While executives have been keen to move towards digital agility in theory, they’re hard pressed to practically apply 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, one of the main areas 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, than the code being written for a company’s software. So, 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.
DevOps for Database requires the same best practices as source code:
- Deployment practices need to be enforced
- Version control needs to be enforced
- Safe automation processes need to be created
- The database needs to be included in the continuous process and feedback loops, etcetera
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 the database 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 DBAs 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’s why 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 being asked 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?
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 and higher quality. If you don’t extend the principles and practices to every corner of the enterprise and every stage of the life cycle, you aren’t really achieving digital agility.
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 so many still struggling to bridge theory and practice, prepare to keep hearing about the novelty of DevOps.
Do you know these 10 things? Check out our agile development infographic.