What to automate? Which parts of the delivery process are good candidates? Which applications will benefit from automation? At first, those sound like silly questions. Automate all your repetitive processes. If you think that you'll do the same thing manually more than once, automate it. Why would you waste your creative potential and knowledge by doing things that are much better done by scripts? Yet, an average company does not adhere to that logic. Why is that? ...
When was the last time your company experienced a significant database error? If it happened in the last 3 months, you’re in good company. A recent study conducted by DBmaestro asked 244 IT professionals this very question; 60% of respondents reported a crash or significant database error occurring in the last 6 months. Roughly one in ten respondents reported a serious database problem in the past week.
The survey, conducted online in October, sheds light on common practices in database management, errors and risks, as well as the rate of adoption of DevOps practices throughout all R&D functions. The results show that while DevOps practices have been widely adopted and utilized in application development, databases have been left behind. Crashes and major errors are prevalent among respondents, and even more so among companies that attempt to push database changes often.
Database Errors are Costly, Frequent, Dreaded
Database errors can be expensive; estimates vary, but studies show that an hour of database downtime can cost your business anywhere from $100,000 to $600,000+ an hour. These estimates have been growing steadily in the last several years, and can be even bigger for companies that rely heavily on timely database data retrieval for business operations.
While there can be many different causes for serious database errors, the 2018 Database Devops Survey reveals that the top causes are accidental overrides, invalid code and conflicts between teams. These three horsemen of the apocalypse account for over 50% of major database errors, respondents report.
For these reasons, it comes as no surprise that pushing changes to the database involves dread. In fact, over one-third of respondents reported that they are anxious about pushing database changes at least half the time.
DevOps Practices Used Widely – But Not for Databases
The fear-inducing errors that lead to crises when pushing new changes have all long been solved in the world of code development. With the extensive adoption of DevOps practices across multiple industries, similar errors in application development have been reduced to nothing. In fact, when asked about continuous delivery practices, 54% of respondents report that they are fully implemented in at least half of the company’s application development projects.
Adoption of these practices for the database is slow and lagging, the report shows. Only 36% of respondents report that they've implemented continuous delivery practices for database changes. On top of that, most respondents report that only the DBAs are allowed to push changes, often making them a bottleneck in the process.
It comes as no surprise that the result is slow, infrequent changes deployed to the database. Almost half (46%) of respondents reveal that they are only able to deploy database changes once or twice a month, a fact that stands in stark contrast to environments where CI/CD practices enable multiple deployments daily. In fact, only 14% of respondents currently have that capacity for database deployments.
Onward and Upward
The bottom line is clear: database needs to hop on the DevOps bandwagon, and fast. The only way to eliminate and prevent major database errors is by automating processes and adopting continuous delivery practices, stat. In turn, this will also improve the ability to push database changes often and fast, making the database as agile as any other part of the company’s development process.