How to Avoid Falling Into the Trap of Semi-DevOps

As we all know, the goals and working behaviors of development and operations teams vary drastically. And, these differences become even more apparent when you’re trying to follow DevOps and Agile development methodologies. I came across an old article on this very topic. The author uses the Obama campaign as a case study, demonstrating how “the tech team collapsed the boundary between engineering and operations.”

One very valid point the author makes is that “when trying to get DevOps right, you have to solve the same problems over and over again, and if you don’t solve the biggest one — educating the owner on the iterative nature of DevOps — you’ve got a problem.”

In the case of Agile, development teams must produce new products (or updated ones) quickly. The operations teams on the front line must then utilize those newly released products. And while there was a substantial gap between the different roles of the teams participating in Obama’s campaign, there is also a similar gap between the roles present in other scenarios.

Regardless of the type of organization, there is application development, IT development, and database development – each with its own standards, tools, and methods. Unless all three areas of development are working collaboratively, at the same level, the organization will only be able to achieve portions of DevOps. Semi-DevOps, so to speak.

For example, some members of the development or operations teams will work tirelessly on manual activities, while others sit back and relax, thanks to the benefit of automation. Application developers are the ones most likely to have these automated processes, so they will continue to rapidly produce products, increasing backlogs on the database development side, where automation is typically lacking.

Download our popular eBook “In Database Automation we Trust”

Things have to change. Now is the time for database development teams to close this gap – which has been present for as long as two decades. A comprehensive database change management solution, with real database version control capabilities such as check-in and check-out on the database objects, can help. The solution must also have a version control repository, to support the complex database structure and maintain dependencies and reference data, which will be utilized when generating the deployment script. And finally, the solution should automate all related activities, so – like their peers who oversee application development – database developers can take advantage of the efficiency and productivity gains that come with automation.