Database, Application and Version Control and Everything In Between
I recently had a discussion with a DBA, who reminded me of days long ago when I was a DBA for almost 15 happy years. I worked with IMS, DB2, Oracle, MS-SQL, SAP ASE, and MySQL. I usually started as the only DBA in the organization, then hired people and established a DBA team. After my DBA days, I switched to the world of R&D where I managed the development of tools for DBAs. Today, I’m the Director of Products Management at DBmaestro, where I am still immersed in the database world. However, this time my products are not just for DBAs, but also for developers (in order to make a DBA’s life easier).
Looking back, I remember that my role as a DBA did not really fit into the scope of R&D, as I was also in charge of production and everything that had the word “database” in it. For example, I was responsible for keeping track of the developers’ changes, creating their initial environments, and merging their environments with changes from other teams. On top of all of that, I was expected to be involved in design, making sure the database and applications were well-tuned.
As you could expect, I found myself burdened by the tedious tasks of merging, creating environments so that the developers can work and was less involved in the designs. I didn’t even have time to run performance tests or keep track of the changes being made as I would have liked to.
Being lazy, I always tried to automate my work so I could be more efficient, but it took me several months to reach an acceptable level of automation. It usually involved taking up the developers’ time to create the tools I needed (in order to support them).
So, what was missing for me during those happy days? I definitely needed something that would have allowed me to be more in control of the changes developers made in the database. Better control over schema changes would have allowed me to be more involved in design, while more control over changes to database code (procedure, function, package, etc…) would have enabled me to fix performance issues before they occurred in production.
Of course, I could have solved those issues if I didn’t allow the developers to make changes directly in the database (only I could make database updates), and forced them to work with scripts. However this approach would not have lasted even a week.
Merging and synching also consumed a tremendous amount of my time. I found myself spending about 5 to 7 days a month merging environments for development. The reason that this task was done by me and not the developers was because: a) it involved a database; b) not every developer was up to this task as it required a deep level of database syntax and understanding of the dependencies between database objects.
Looking now at the tools that exist today, I can only regret that I didn’t have them then.
For example, a Database Enforced Change Management (DECM) solution will allow developers to work directly on/make changes to database objects. I can then look at the reports and see who made what change, when, where and why. The fundamental requirement for this solution is that the work on the database object must be synchronized between all team members. Otherwise I would be interrupted by a developer complaining that his/her code disappeared (as someone else compiled the same package, procedure, etc.).
But DECM wasn’t around in my DBA days, so I had to use what I could. I used file-based version control, which was used by the developers for their development, and tried to make it work on the database. This posed a great challenge because sometimes the developers forgot to sync between the database and the file-based version control processes and I paid the price (no hard feelings).
What I needed was some way to turn the development process into a single enforced process, as they had in their native application code (Java, .NET, C#, C++, Cobol, etc.).
I also wanted a reliable way to easily merge environments (preferably with a click of a button). Being confident in the automation is important; otherwise I would not use it. Compare and Sync tools (cutting edge technology at that time) didn’t help me much. One example of why was when the database object in my target environment was not the same as in my repository. Because developers sometimes forgot to update the file-based version control repository, I couldn’t be sure where the correct definition of the object was, so I had to ask my colleagues questions.
Another example was when I had to merge (not just override) the development database with what existed in the file-based version control repository. The challenge here was to catch the work-in-progress objects and avoid overriding them with the code in the file-based version control.
If I had a DECM solution back then, I would have been happier and more productive as a DBA and would have been able to use my knowledge and experience more effectively. If you are a developer, team leader, or R&D manager, I recommend that you find ways for you and your team to help the DBA be more productive, so you can gain from their experiences.
Now that I’ve told my story, I’m very interested in your comments.
*The article first published here
About the Author
Uri Margalit is a product executive at dbMaestro –the pioneer and leading provider of Automation and DevOps for Database solutions that enable control of the database. Uri possesses over 15 years of experience, and has a proven track record for taking innovative new ideas to the market. With a passion for understanding and translating market requirements into working products and solutions, Uri is able to effectively lead product teams in enterprise software and systems management. Uri is a regular speaker at worldwide conferences such as Symantec Vision, ODTUG, Oracle Week, and more.
Connect with Uri in Linkedin