devopsy.kinsta.cloud

Author: Yaniv Yehuda

  • 2018 Database DevOps Survey: Crises Still Prevalent, Mostly Avoidable

    2018 Database DevOps Survey: Crises Still Prevalent, Mostly Avoidable

    DevOps is not just a buzzword anymore, it’s a reality. With the unfolding evolution of automation and continuous delivery, DevOps practices have become an industry standard. Adopting technologies for rapid deployment has become essential for companies that wish to maintain their status as serious players in their industry, both from cost and production standpoints.

    But while DevOps is a significant piece of the IT puzzle across multiple industries, many have yet to adopt these crucial continuous delivery practices for their databases.

    In October 2017, DBmaestro conducted an online survey highlighting the challenges and best practices of companies using or looking to implement DevOps, with a focus on databases. The survey respondents are 244 IT professionals from around the globe, representing a variety of industries. The “2018 Database DevOps Report” revealed widespread adoption of DevOps practices on multiple levels across industries.

    DevOps Adoption Rates Increasing, Databases Still Lagging

    More than half of the companies surveyed (54 percent) are actively using continuous delivery practices and tools for application development in 50 percent or more of their IT projects. The same cannot be said for databases, however; to date, only 37 percent of respondents have adopted continuous delivery for databases.

    Continuous Delivery Adoption Rates

    Interestingly enough, while the rate of continuous delivery adoption for databases clearly lags behind that of application development, it remains an area of great interest for companies in 2018. In fact, 17 percent of survey respondents indicated plans to adopt continuous delivery for just that purpose.

    DBAs Face Huge Responsibilities, Huge Risks

    Slow adoption of continuous delivery practices for databases leaves companies exposed to costly errors. The report offers insight into the biggest challenges companies face with database changes.

    In many cases, the bottleneck in the process lies in the division of responsibilities: 59 percent of respondents reported that DBAs are the only ones in the company allowed to make changes to databases.

    Drafting database changes is a common task for DBAs, consuming approximately 22 percent their time, according to respondents. Deploying those changes, however, comes with big risks; when not done properly, deployments can cause significant downtime, impact the database’s performance and even result in data loss. It doesn’t help matters that database crashes remain disconcertingly common—almost one-third (28 percent) of survey respondents experienced a significant problem in the past month alone.

    Last Significant Problem in Database

    The good news is that many of the issues that can occur when database changes can be addressed through the use of release automation tools for databases, similar to what DevOps has been using for years in code development.

    Database continuous delivery not only assists in preventing mistakes; by simultaneously accelerating the release management process and making it more resilient, the results are faster database change deployment and fewer database errors.

    Database DevOps is (Still) the Solution

    Why do errors occur when deploying database changes? According to survey respondents, 19.3 percent attribute the biggest cause of errors to accidental overrides, followed closely at 19 percent by the use of invalid code. Rounding out the top three error causes, at 18 percent, are conflicts that occur between different teams.

    Database Change Errors

    Do these problems sound familiar? They should: Each of these issues has in the past been a challenge in the world of application code development. As far as application code development goes, version control management and automation of the application release process solved these problems. Therefore, it shouldn’t come as a surprise that the key to eliminating change errors lies in adopting these same methodologies and technologies for the database environment.

    Six percent of respondents reported that their company has no plan to adopt database DevOps practices. With database outages costing an estimated $8,851 per minute, can your company really afford not to?

    — Yaniv Yehuda

  • 3 Ways Manual Processes are Risking Your Development Cycle

    3 Ways Manual Processes are Risking Your Development Cycle

    During my two decades in IT, I’ve seen the demand for Agile and its associated methodologies grow. At the same time, however, I’ve witnessed the database being left behind.

    DBmaestro, where I am co-founder and CTO, recently conducted a survey titled, “Database Deployment & Development Risks,” to gain insights into the risks associated with various database development practices. The survey focused on manual processes used throughout the development cycle.

    The results revealed two divergent realities: Despite respondents, from diverse sectors, overwhelmingly recognizing the risks associated with manual process for the database, many organizations continue to use processes and solutions that don’t fully automate the development cycle.

    One area where this was particularly apparent was with the source control. It’s imperative that development teams are able to trust their source control. But even when standard source control solutions are being utilized, 70 percent of those surveyed are still interjecting manual processes.

    What that means is that even though many of these professionals have some type of solution, they still see a clear and present risk because:

    1. When integrating changes, it’s possible for one developer to wrongly override valid changes with older revisions from other development branches, a potential concern that nearly 90 percent of survey respondents associate with risk. Still, more than half (53 percent) of the IT professionals surveyed integrate changes, creating the possibility that such overrides may occur.

    Nearly three-fourths (70 percent) reported having a database source control, but 53 percent reported that they continue to have problems that a more adequate source control solution should resolve. In this case, there is a problem with the source control tool implemented.

    2. The database may not be in sync with the version control repository. Ninety percent of the IT professionals surveyed associated the potential for these sources to be out of sync with risk. What’s more, 72 percent of those surveyed admit that their database may not be in full sync with the version control repository.

    3. Introducing changes without first verifying each database object vs. its version control revision to ensure each database object is up to date is a process that nearly 90 percent of survey participants associate with risk. Despite a widespread awareness that failing to verify accuracy between database objects and database source control before introducing changes is a risky practice, 53 percent continue to do so.

    That means that the remaining 47 percent of respondents do not trust their source control solution regarding the database code and are implementing steps to validate it matches the database before introducing changes.

    While interjecting manual steps can help alleviate the risk associated with the possibility of overriding critical changes in the database, it’s time-consuming, and manual interruptions to the continuous delivery cycle introduce risks of their own. When you can’t place full trust in source control, two developers working on the same database code or objects can easily override or revert critical changes introduced by the other developer when the script is updated in the database—sometimes with disastrous consequences.

    Only a Database Enforced Source Control solution that covers database lifecycle management (DLM) from development through build and deployment can create a “Single Source of Truth” for your database development assets. This allows you to gain trust in your source control and implement the rapid changes today’s development cycles demand—without plugging the process with time-consuming manual steps. Database Enforced Source Control promotes complete trust in your source code, allowing developers to work simultaneously on the same database objects without the risk of overriding important changes when scripts are updated, promoting true synchronization across dispersed development teams.

    Download the complete results of the 2015 “Database Deployment & Development Risks.”

    About the author:
    image001Yaniv Yehuda is the Co-Founder and CTO of DBmaestro, an Enterprise Software Development Company focusing on database development and deployment technologies. Yaniv is also the Co-Founder and the head of development for Extreme Technology, an IT service provider for the Israeli market. He was a captain in Mamram, the Israel Defense Forces computer centers, where he served as a software engineering manager.