Building out processes and mechanisms for automated code deployments and testing can be quite a lot of work and isn’t easy. Now, try the same thing with data, and the challenges just shot through the roof. Anything from the simple fact that you must maintain the persistence of the data to data size to up time, and you have real problems in front of you.
However, adopting database deployment automation and testing has enormous benefits. Faster, safer, production deployment enhances the protection built around your production systems. Whether we want to use the loaded term of DevOps or not, the benefits of this style of development and deployment are easily documented and measured.
So, why are so few people doing it?
Conservation of Momentum
If we were talking about a mechanical system that we wanted to modify so that it moved faster, we’d have to address the simple concept of the conservation of momentum. The core idea here is that an object in motion will be constant unless acted upon by an outside force. Same thing goes for an object at rest.
If we go back about 30 years or so, deployment automation of applications was getting going good and strong. Team based development lead to the use of source control repositories in order to help the team manage changes. Having this source of truth lead to the automation of deployments. Ultimately even the development of DevOps style automation of builds, deployments, testing, and all the rest.
At the same time as we were building out this stuff on the application side of things, we tried to do the same with databases. Very quickly, almost immediately, it became clear that databases were going to be a pain the bottom. There were no tools that helped us build & maintain a database through scripts. We were forced to do it all by hand. Add to that the fact that deployments back in the good old waterfall days only happened occasionally, so we had enormous scripts that had to be maintained, built, deal with. Again, no tools, little process, so each of us was left on their own. Most of us just figured out how to put together giant scripts and then test them as best we could.
In other words, our automated deployment object had no momentum. It was sitting still.
If we go back 15 years or so, DevOps and other means of automation, were introduced as a concept. Happily, right around this time, a number of different tools were introduced that suddenly changed the possibilities of database deployment and testing automation.
However, the momentum is still against this. People just aren’t motivated, or organizations aren’t, to put forth the energy to overcome the momentum and move their databases towards automation.
I’d like to know why.
Redgate State of Database DevOps Survey
Redgate is once again running our State of Database DevOps survey. Please, take the time to go and fill it out. Especially if you’re not moving towards database deployment automation. Let us know why.
A few pieces of incentive. First, for every survey, we’re donating to charity. Second, as usual, we’ll be sharing the results of the survey. You can figure out how you stack up against the industry in terms of adopting faster, safer, means of deploying databases.
Heck, maybe this information will help you overcome the inertia that’s keeping you from moving faster.