devopsy.kinsta.cloud

Author: Matt Hilbert

Achieving Business Maturity with Database DevOps
Companies have seen unprecedented change over the past year and a half, with IT teams trying to help businesses weather the storm by meeting customer demands for services and products to be delivered in new ways while adjusting to remote work. As more companies introduced hybrid approaches to their workplace, a particular trend began to emerge: DevOps adoption.

Many adopted DevOps to navigate the new landscape, boosting software delivery and operational performance with advanced application and database development practices. In fact, research from Redgate Software indicates that DevOps adoption reached its peak earlier this year, with 26% of enterprises leveraging DevOps across all projects—a significant increase from previous adoption rates.

Although not all companies have been quick to adopt for fear of disrupting existing workflows, a technical skills gap or lack of buy-in from management, there is a strong case to be made for why adopting DevOps practices, including for the database, can help businesses better manage the evolving tech environment.

Adopting Automated Deployments

Companies everywhere migrated databases to the cloud over the course of the past year, and that trend shows no sign of slowing. Analysts at IDC predict that by 2022 more than 90% of enterprises will rely on a mixture of on-premises/dedicated private clouds, multiple public clouds and legacy platforms to meet their needs. One of the best ways to help maintain that data is to implement DevOps processes for those databases and automate deployments. This provides a host of benefits, including:
- Preventing software errors: Manual database migrations often come with a host of errors that lead to downtime, rollbacks and rework. It’s far better to rely on an automated process that is robust and repeatable and can be implemented across all databases to ensure they’re updated in the same, reliable way.
- Staying in the loop: Knowledge of how to release updates and changes is often limited to a handful of people or even just one person. If, instead, it is part of the system and development process, it ensures everyone is in sync with updates and developments and allows anyone on your IT team to handle deployments.
- Guaranteeing quality and consistency: For companies with security and compliance concerns, the predictable and repeatable processes that automated database deployments introduce ensure nothing is left to chance, while providing an auditable record of exactly what was changed, when and by who.
Although the research shows 20% of companies cite cost as a roadblock to automation, avoiding automation will leave businesses at a disadvantage as they prepare for the coming year.

Creating Communities of Practice

When asked how they decide the strategic direction and planning for DevOps, the most popular answer from respondents was communities of practice. This concept was proposed for the first time in the early 1990s, and the practice has seen increased popularity among IT teams recently. It’s described as groups of people who share the same passions or concerns for something they do and often learn how to do that task better based on their regular, frequent interactions.

These various communities—regardless of whether in-person or virtual, given the current environment—help foster intrinsic motivation in employees and improve overall decision-making and encourage innovation. According to Redgate’s research, over a third of respondents noted that a community of practice makes decisions, provides recommendations or is consulted before DevOps strategies and planning are put into place. Another interesting point from the research is that the adoption of communities of practice correlates with company size. Enterprise and medium-size companies reported adoption rates of 38% and 36% respectively compared to only 28% adoption in small companies.

As companies grow and teams mature, these communities not only benefit the organization by bringing more diverse minds to the table when making decisions but benefit individuals by supporting development, enabling networking and improving recognition across the organization.

Managing Cross-Database Estates

Redgate’s research found that 70% of organizations now have more than one database management system in use, and 48% have teams working on three or more different databases. One possible reason for this is the increased adoption of cloud databases. With a large range of cloud databases and platforms in use, each offering different advantages, teams are now making choices based on specific use-cases. There was an increase in the share of respondents using cloud-native databases such as Azure Cosmos DB, MongoDB and Snowflake compared to last year, for example.

With cloud adoption accelerating due to the pandemic and the need for technologies that can be managed, operated and accessed remotely, the advantages of introducing DevOps processes to maintain database changes and ensure version control have never been clearer. Teams that have automation and advanced development practices in place can continue building and deploying software as smoothly as before the pandemic, even when working remotely.

Instead of working to build up processes and procedures, mature DevOps teams can focus their efforts on solving problems and ensuring higher quality of code, without the need for laborious manual tasks or code reviews that automated systems perform more reliably.

Making the Case for Database DevOps

When teams are physically separated, working disparate schedules and dealing with their own challenges at home, the more companies can do to reduce workloads and help them focus on value-added work creates a happier workplace and improves the chances for business success. The rise of DevOps for both application and database development helps mitigate many of the challenges organizations face as part of their digital transformation journeys. It’s going to help IT teams remain productive when working remotely and encourage them to explore new database platforms, both on-premises and in the cloud.

With remote and hybrid work the new normal for the future, companies that set their sights on adopting DevOps across the company will only see these benefits increase.
September 27, 2021
How DevOps Is Driving the Demand for Cross-Platform Tools

The demands of modern business mean companies today want choice when it comes to the technology they deploy. Gone are the days when they rigidly used a single environment–instead they want to be able to use the best of technology from vendors and be sure it will work across environments seamlessly.

Whether it’s on-premises or the cloud, Linux or Windows, SQL Server or Oracle databases or even at the development tool level, they want their people to be able to use the Integrated Development Environment (IDE) they’re most at home with, yet still be able to share third party tools and resources. This requirement for greater choice is being driven by three key factors.

The Growth of DevOps

Firstly, the spread of DevOps is leading to greater collaboration between departments within an organization, as is the rise of the cloud.

In the past, for example, database administrators (DBAs) and application developers worked in their own silos, with their own technology, without needing to interact. DevOps has radically changed this, bringing them together in teams where workflows merge and complement each other. They need to follow the same processes, such as continuous integration and continuous development, but have very different technology backgrounds and skillsets. DBAs may know Microsoft SQL Server Management Studio in-depth, while developers are used to creating code in IDEs such as Visual Studio. SQL Server experts may also choose to work in Windows, Linux or a combination of both environments.

Forcing everyone to use a single environment will clearly be counter-productive and lead to a drop in efficiency. At the same time, however, letting them use different approaches can harm the very teamwork that DevOps relies upon. Instead, vendors need to allow their software to be used and managed through multiple approaches, ensuring that companies get the best out of their people and investments.

Technology Everywhere

Marc Andreessen coined the famous phrase “software is eating the world“ back in 2011. Since then every business has seen technology spread throughout its organization, with digital transformation initiatives increasing the software development required for all departments and functions. At the same time, data has become central to better business operations, enabling brands to better understand their customers, provide an improved experience and deliver more tailored products and services.

This has resulted in the rise of full-stack developers who are now responsible for both application and database development. Redgate’s 2019 State of Database DevOps Report revealed that 77% of developers now switch between coding in application languages, such as JavaScript in one moment to writing T-SQL for the database the next.

A problem arises if different IDEs are required which inevitably leads to an increase in the need for training alongside a decrease in efficiency and performance.

Growing Cost Constraints

In today’s competitive marketplace, every business investment is subject to a high degree of scrutiny to check that it’s delivering a demonstrable ROI. While budgets in the past might have allowed organizations to use different tools or systems in each department, there is a growing need to avoid duplication and the costs that it brings. Open source and free tools are also being widely deployed in even the largest organizations. This drive for greater efficiency obviously needs to be balanced against the skills and experience of in-house teams, who want to be able to use tools they favor and are accustomed to.

Conclusion

All of these three factors are driving a new approach from software vendors. Whereas in the past they might have focused on integrating their tool with a single IDE, they now need to offer choice. This allows a common development approach to be adopted while still enabling collaboration across the business, particularly when it comes to DevOps. It preserves investment in the skills and tools that different groups know best, increasing efficiency, yet also eases the introduction of initiatives like full-stack development.

Driven primarily by DevOps we’re moving into a more heterogeneous world, and vendors need to ensure that they are supporting companies so they can work in the ways they want, with the tools they want, if they want to remain relevant and successful.

— Matt Hilbert

November 15, 2019
The Impact of DevOps on Database Monitoring and Management

The rise of DevOps has broken down silos and brought database administrators (DBAs) and application developers closer together to deliver software faster and in a more agile manner. This near-constant change driven by DevOps is reflected in the results of the Redgate 2019 State of SQL Server Monitoring Report.

It reveals that 73% of organizations now deploy database changes multiple times per month, and 15% deploy multiple times per day, driven by DevOps. Yet, this is just one of the challenges DBAs face today. The research also identified the size of database estates is growing–45% said they will have more to manage over the next year, with 43% remaining the same.

Additionally, they are increasingly looking to migrate their databases to the cloud (cited as their biggest challenge by 22%) and are seeking to solve performance issues. Perhaps unsurprisingly, given these greater workloads and more frequent changes, human error is the largest cause of issues (22%), ahead of capacity problems and bad deployments.

Managing in a DevOps World

The database is now a core part of DevOps for many organizations and DBAs need to work more closely with their developer colleagues, adopting new technologies and tools to ensure business success.

This essentially involves DBAs focusing on the following distinct areas.

Standardizing Approaches Across DevOps Processes

The monitoring report highlighted human error as the biggest cause of problems for DBAs–and with larger DBA and developer teams now working on databases together, adopting standardized processes is vital to flagging issues early and preventing later problems. Otherwise, what starts as a minor issue can swiftly escalate to become a significant business crisis.

As well as standardizing processes, organizations should look at rolling out industry-standard coding tools across the entire team. This will ensure a consistent approach, not matter who is writing, reviewing or editing code. Introducing a team style for database code, rather than having the code written in many different ways, for example, will make the code base consistent and clear and minimize the confusion that lead to errors. At the same time, merging code early and often with version control tools will ensure you have a known, shared codebase on which to work, and provide a single source of truth that can always be relied on.

Automating for Speed and Consistency

Developers who have adopted DevOps already see the value automated processes such as continuous integration, continuous delivery and continuous deployment provide. Automation not only speeds up development, avoids manual errors and reduces laborious work, but also provides a full audit trail for regulatory compliance.

Extending this to the database can deliver major benefits for hard-pressed DBAs. Every time a change is committed to version control, for example, a continuous integration process can be triggered to test the change and flag up any errors in the database code. The errors can be fixed immediately and tested again, before the change is then passed along to a release management tool where it can be reviewed before being deployed to production.

Overall, automation dramatically brings down time to market, but organizations need to ensure they have the right tools and processes in place if it is to be truly effective.

Stepping Up Monitoring to Drive Continual Improvement

One of the mantras of DevOps is continual improvement, and that applies equally to database DevOps. Monitoring is a key part of this. On one level, monitoring tools highlight potentially disruptive performance issues (cited by DBAs in the research as a major challenge), enabling them to be fixed quickly.

Beyond this, they also deliver the insights and trends companies need to improve, helping them optimize operations moving forward. Thanks to a combination of DevOps and the growing importance of the database to business success, many organizations are already sharing this information. For example, 40% give developers access to their monitoring data, according to the research, which helps to enhance performance by highlighting opportunities for improvement.

Guarding Personal Data and Ensuring Regulatory Compliance

We’ve all seen the spread of data privacy regulations across the globe. Over 60% of the world’s population is likely to be covered by more stringent legislation in the near future, with California joining the EU in enforcing new regulations from January 2020. Organizations need to realize they are now data guardians, not data owners, when it comes to personal information.

At the same time, developers like to have realistic information in order to successfully create and test new code. That means organizations need to adopt tools for data masking and anonymization that can protect confidential and personal information, while still providing realistic and usable data for development and testing. This also gives a full audit trail for regulatory requirements, balancing speed and compliance.

DevOps has broken down the traditional silos between DBAs and developers and the importance of information has put the database center stage. As the latest Redgate research shows, DBA workloads are increasing, meaning they need to adopt new technology and collaborate more closely with developers if they are to successfully manage in a DevOps world.

— Matt Hilbert

August 16, 2019
4 Steps to Introduce DevSecOps to Database Development

Although DevOps was implemented within application development, there is a growing awareness that including the database within DevOps processes is vital to success. We live in a data-driven world and many front-end applications use a database at the back end to collect, process and store customer and user data.

The faster development of applications that DevOps encourages also results in more frequent updates to databases. By excluding database development from DevOps, the database becomes a counterweight to the speed of releases that otherwise can be gained.

This is already being recognized, as demonstrated in the 2019 Database DevOps Survey from Redgate, which found that 77 percent of application developers are now responsible for database development and 75 perent build database deployment scripts.

All of which is welcome news, provided DevSecOps for the database is also taken into account.

While DevSecOps is relatively new (the term was coined in 2012 by Gartner analyst Neil MacDonald), the need for it is a widely accepted facet of DevOps because DevOps radically changes how companies tackle security in application development. Whereas security used to be reviewed and certified at the end of long development cycles with a scheduled window, that window has now disappeared. Hence the rise of DevSecOps, which bakes security into the development process, with tools such as static code analyzers and open source code vulnerability scanners testing code as soon as changes are made.

In the same way that the database must be included within DevOps if the process is to be seamless, companies also need to ensure that DevSecOps is applied to the database. In fact, given the importance of protecting personal data in today’s world, ensuring privacy and security is imperative for both compliance and public reassurance.

In 2017, MacDonald continued his work on defining what DevSecOps is when he set out 10 steps that companies need to follow to protect applications during development. All of these are equally relevant to DevSecOps for the database, with the exception of the second step: Quit trying to eliminate all vulnerabilities during development. Many databases contain personal data, much of which is sensitive, so every vulnerability during database development has to be addressed and resolved.

Looking in detail at Gartner’s list, I’d say there are four key steps that particularly apply to DevSecOps for the database:

Identify the Vulnerabilities

At the center of DevSecOps for the database is the data, which has to be protected from both internal threats such as negligence or accidental exposure, and external threats such as hacking. The biggest problem with data, however, is its size and sprawl. Data is growing at an annual rate of 58 percent, according to IDC, and is now stored in a multitude of different places.

To identify what the vulnerabilities are, the data first needs to be located and classified and its risk identified. Data mapping exercises such as this can be done by hand or with a third-party tool, but it’s important to create a record of every database, including copies used in development or testing, to gain a real understanding of where data is stored and who has access to it. Classifying the data then can be undertaken to identify which data is sensitive and at risk, such as credit card details, and therefore needs to be protected.

Remove the Vulnerabilities

As we’ve seen, the recommendation to not try to eliminate every vulnerability in application development doesn’t apply to the database. Where data has been identified as sensitive and at risk, access must be limited and it cannot be widely shared.

Developers, however, often need a copy of the production database in their development, test, or QA environments to ensure changes will work once deployed. However, those same production databases invariably contain sensitive data that needs to be protected.

One solution is to create a version of the production database with a limited dataset of anonymous data. However, this means it is neither realistic, nor of a size where the impact on performance can be assessed. A second solution is to take a copy of the production database and mask the data manually, but this will age quickly as ongoing changes are deployed to the production database.

Therefore, data masking measures such as pseudonymization, encryption, anonymization and aggregation should be adopted, and companies can use third-party tools to help mask database copies, yet also provide development teams with test data that looks—and behaves—in the same way as real data.

Introduce Secure Coding

While application development typically uses an imperative programming language such as C# or Java, database development relies on a declarative language, such as T-SQL for SQL Server, which is less strict and where the coding standards vary widely.

This has resulted in developers who code in T-SQL having their own styles and preferences. With multiple developers writing updates, this often ends up with code that is confusing, difficult to understand and with errors that can cause deployments to fail.

To overcome this, code should be written in the same style, with a secure approach that follows set standards, put in place by the database administrator. Introducing this secure coding mindset at the point code is written will prevent problems later down the line.

Automate Where Possible

The ninth point in Gartner’s list is to implement strong version control on all code and components, with developers checking their changes into a common repository during the development process, preferably at the end of each working day. As a result, everyone has access to the latest version of the application, and it is always clear what was changed, when it was changed and who changed it.

This is just as true for the database code, which also can be version-controlled, preferably by integrating with and plugging into the same version control system used for applications.

Importantly, once version control is in place, processes further along the development pipeline can be automated. Continuous integration can be introduced, for example, to automatically test changes as soon as they are committed and ensure they are not breaking changes.

Data has been described as the 21st century equivalent of oil, with its use central to success in every organization. Given its sensitive nature, protecting it is equally vital. That’s why all businesses and teams need to ensure they are not only including the database within DevOps, but within DevSecOps as well.

— Matt Hilbert

March 25, 2019
Why You Need DevOps and the Cloud
DevOps and the cloud are not only two of today’s biggest tech trends, but are inextricably linked. Research from DORA’s 2018 Accelerate State of DevOps Report and Redgate’s 2019 State of Database DevOps Report outline a clear correlation between cloud and DevOps adoption, with the two working together to contribute to greater business success.

For example, in the DORA report, those companies that met all essential cloud characteristics were 23 times more likely to be in the elite group when it came to DevOps performance. Similarly, Redgate found that 43 percent of organizations that have adopted DevOps have server estates that are all or mostly cloud-based. This compares to just 12 percent of organizations that have not yet adopted DevOps or have no plans to.

Looking into the link in more detail, research shows that there are four common factors that underpin DevOps and the cloud:

Cultural Openness to Transformation

Adopting DevOps is not just a technical or process change, but one that requires a certain type of culture to be in place. The renowned sociologist Ron Westrum famously categorized business cultures into three groups in his seminal paper A Typology of Organizational Cultures:
- Pathological: Power-oriented, with low co-operation, a culture of shooting messengers bearing bad news and the crushing of novelty.
- Bureaucratic: Rule-oriented, with limited co-operation, a neglect of messengers and a suspicion of novelty.
- Generative: Performance-oriented, with high cooperation, messengers encouraged and a focus on learning from mistakes and embracing novelty.
It’s no coincidence that DevOps and cloud adoption both thrive best in a generative culture that is open to innovation and is focused on collaboration and continual learning and improvement. In fact, the DORA research found that a generative culture correlates with elite performance when it comes to software delivery, and that this group is 1.8 times more likely to recommend their team as a great place to work.

Building this open culture requires team members to feel safe about taking risks, rather than continually covering their backs, as well as good communication from leaders. This psychological safety underpins the continuous improvement mantra of DevOps and the innovation that the cloud delivers.

The Importance of the Cloud to Enabling Faster Software Delivery

As the DORA report found, cloud users are more likely to be elite performers when it comes to DevOps. But the research also highlights that there is a lot of confusion about what “moving to the cloud” actually entails. The National Institute of Standards and Technology (NIST) defines cloud computing as having five essential characteristics:
- On-demand self-service
- Broad network access
- Resource pooling
- Rapid elasticity
- Measured service
Just 22 percent of DORA respondents agreed or strongly agreed that they met all of these criteria. Those that did were 23 times more likely to be elite performers when it came to software delivery. This shows that simply moving to the cloud alone doesn’t lead to DevOps success—the switch needs to be implemented professionally, in a planned way. This goes back to culture—the same openness to innovation has to underpin both, DevOps and the cloud, to realize their full benefits.

Breaking Down Barriers

One of the key points of a generative culture is openness to collaboration, which is clearly essential to DevOps and, in particular, incorporating the database into DevOps flows. In the past silos, rivalries and even animosity built up between application developers and database administrators (DBAs). In many ways this isn’t surprising—developers are focused on getting new code out of the door, while DBAs are seen as protecting data and databases and ensuring uptime.

However, for DevOps and the cloud to succeed, teams need to take a holistic view that breaks down team barriers. Redgate’s research shows that this is now happening, starting with the working relationship. Sixty two percent of respondents characterized the relationship between DBAs and developers as either good or great, up from 58 percent in previous years. This is heartening—only 13 percent said the relationship was poor with DBAs completely siloed, unaware of what’s happening in development, and deploying database changes to production in isolation.

In teams that have adopted DevOps across all projects, the great and good collaboration rises to 76 percent, with 41 percent stating great collaboration—almost double the overall average.

This collaboration is also reflected in daily activities. For example, over three-quarters (77 percent) of application developers are also responsible for database development and building database deployment scripts. In 47 percent of companies, developers are also responsible for the deployment of database changes to production.

Putting in Place the Right Tools

The collaboration behind successful DevOps and cloud adoption requires companies to introduce common practices and common tools across the entire process. This is reflected in figures from the Redgate research, with a growing adoption of the same tools within application and database development. Version control is now used by 83 percent of respondents for application development, and 55 percent for database development, rising steadily from 81 percent and 53 percent respectively in 2018. Particularly encouraging is the significant uptake in continuous integration—a cornerstone of DevOps—which is now used by 53 percent of respondents for application development and 27 percent for database development, up from 40 percent and 21 percent in 2018.

All of this is leading to increased usage of third-party tools across DevOps processes. The most substantial year-on-year change is the use of third-party provisioning tools—which has doubled from 12 percent for the application and 8 percent for the database in 2018 to 25 percent and 15 percent respectively this year.

In increasingly competitive markets, companies rely on software and data to differentiate themselves and drive success. And this, in turn, is underpinned by DevOps and the cloud, which provide the agility, speed, quality and flexibility to develop and deploy software more quickly and safely than before. Businesses therefore need to adopt both if they are to achieve elite performance across their software operations.

— Matt Hilbert
March 12, 2019
Integrating the Database into DevOps for Business Success
The benefits of DevOps have been known for some time, but this year’s “Accelerate: State of DevOps” report shows that successful companies are extending the advantages they get from adopting it. The longest-running research of its kind, the report from DevOps Research and Assessment (DORA) represents five years of work surveying more than 30,000 technical professionals worldwide.

Based on their input, the report previously split organizations into low, medium and high performers. This year it added a new category—elite performers—who are embracing DevOps to raise the bar when it comes to the benefits they gain. Elite organizations are able to deploy code 46 times more frequently than low performers, lower lead times from committing to deploying changes to less than one hour (compared to one to six months in low performers), and recover from incidents 2,604 times faster.

The Importance of the Database

For the first time the report also focuses on the vital importance of the database to successful DevOps, echoing research from Redgate. As it points out, deploying changes to the database is often a bottleneck, slowing down DevOps. To overcome this, the Accelerate report recommends integrating database work into the software delivery process, based around four good practices:

Strong Communication and Cross-Team Collaboration

Traditionally, the teams involved in application and database development have had different priorities and responsibilities. The biggest concern with the database was to limit change to keep data safe, while application development was all about creating features, often without regard to what impact they would have on the database.

With DevOps, this has changed. The faster releases of smaller changes it encourages means the database cannot be a logjam at the end of the development pipeline. Instead, it needs to be part of the same workflow, so good, ongoing communication is vital.

In many organizations this is already happening: Fifty-eight percent of respondents in Redgate’s 2018 “State of Database DevOps” survey said that collaboration between developers and database administrators (DBAs) was either good or great, showing that the processes and teamwork are in place to break down any walls between departments.

Comprehensive Configuration Management

Using configuration management tools for software development is a central part of achieving successful DevOps results. To avoid issues, these same practices and tools need to be extended to cover the database as well. Handling changes systematically creates a seamless flow that enables faster releases and dramatically reduces issues—vital when more than a third of respondents to Redgate said they deployed database changes either daily or more than once a week.

Extending Version Control to the Database

As part of taking a holistic view, the Accelerate report found that extending version control from application code to database code delivered major benefits. Elite and high performers store database changes as scripts in version control and manage these changes in the same way as application changes. This is a task that is shared between DBAs and developers—75 percent of respondents to the Redgate survey said that application developers now build database deployment scripts, and were responsible for deploying these database changes to production in nearly half (47 percent) of organizations.

Building a Strong Culture

Culture is a strong factor in whether DevOps succeeds or fails in an organization. This is unsurprising given that DevOps is a very different process to those it replaces, focusing on speed, collaboration between teams and a willingness to be open and continually learn and improve.

Most people are now familiar with the work of sociologist Ron Westrum, who characterized the culture within organizations as one of three types:
- Pathological (power-oriented) companies work in silos, don’t cooperate and are quick to apportion blame if something goes wrong.
- Bureaucratic (rule-oriented) companies are more open, but are still suspicious of novelty and tolerate limited co-operation between teams.
- Generative organizations are most suited to successful DevOps, with a focus on co-operation, surfacing problems, breaking down silos, holding postmortems to understand why things have not gone well and continually experimenting to drive improvement.
To create the right culture for DevOps, leaders need to build trust with their teams, empower them with autonomy and rely on strong communication to ensure that everyone understands their role and overall objectives.

Summary

The latest “Accelerate: State of DevOps” report has a simple, top-line message: Higher software delivery performance enables better business outcomes. Achieving this requires taking a development-wide approach to DevOps, incorporating the database seamlessly into DevOps flows, communicating and collaborating between teams, sharing technical practices, and building a strong, open culture across organizations. Only then can businesses become high or elite performers, with an agile infrastructure that underpins their success.

— Matt Hilbert
October 26, 2018
Making the Database Key to DevOps

Here are three best practices for doing DevOps with the database

The speed of business today demands that the development and deployment of applications is fast-moving, with frequent yet error-free releases. That’s why the adoption of DevOps is trickling down from Amazon, Facebook, Google and the other usual suspects to every company that relies on technology to drive its communications or sales with users.

The database is now entering the picture, too, because when front-end applications are changed, there often needs to be a change at the back end to accommodate it. Redgate’s 2018 “State of Database DevOps Survey” found that more than one-third (35 percent) of organizations are deploying database changes either daily or more than once a week.

Some are working even faster, with companies such as online travel provider Skyscanner moving from releasing database changes once every six weeks to 95 times a day when it first introduced database DevOps—and increasing the frequency since.

This accelerated speed of delivery is a key benefit of database DevOps, with 28 percent of respondents to the DevOps survey quoting it as the biggest advantage. But as releases become more frequent, so, too, does the chance of something going wrong, along with the difficulty of pinpointing the exact cause in a large, complex, fast-changing environment.

Database DevOps Best Practices

Even with the most comprehensive testing, issues can occur. And as more and more developers now work across both the application and database, and with larger, more disparate teams, companies need the ability for everyone to drill down quickly to identify and fix issues.

Achieving this means bridging the database and application worlds by focusing on three key areas.

Deployment Choice

Different developers and database administrators will use specific tools to deploy database changes. This can depend on their experience, skills or simply that they have a preference for a particular way of working.

You need to be able to allow this choice, but without affecting the ability to track down issues. Therefore, ensure that you have a monitoring tool in place that can pinpoint not just when and where changes were made, but which tool was used. This will help quickly find the root causes of any issues, by providing the full context around the problem.

A Single View

Data is the lifeblood of many businesses—companies now have more and more databases within their organization, often spread across different locations. However, no matter how complex your IT environment or the size of your estate, you need to be able to monitor database performance from a single place. That way, you can easily identify issues and pinpoint precisely which database is being affected.

Wherever a database is, and whatever the distance it is being monitored from, the monitoring also needs to be in real time, with updates in seconds, not minutes, providing the reassurance that you always have the latest picture of what is occurring. This enables you to become more proactive, spotting developing trends and issues such as deadlocks or blocking processes, before they affect your users or overall performance. Having a single, up-to-date view is therefore essential when integrating the database into DevOps processes.

Fast, Customizable Alerts

The ability to make frequent, reliable, repeatable changes to the database as well as the application is integral to DevOps flows, and monitoring them means evaluating dozens of different parameters constantly.

Clearly, it’s impossible to keep an eye on everything that is happening, even when events are condensed to a single monitoring screen. Therefore, ensure you’re able to easily create and customize alerts for specific parameters that are important to your business, so that they don’t get missed. This enables you to better understand DevOps processes and ensure that you have early warnings of potential complications, no matter where they occur.

For the database to be an integral part of DevOps, organizations need a complete, interoperable view of their entire estate so they can track down problems, monitor processes and spot issues before they affect users. That view should be equally available to the whole DevOps team, including developers, so they can see immediately what effect their latest change is having and take the appropriate action to fix any breaking change while it is still fresh in their mind.

Only then can databases take their key place in DevOps flows, eliminating bottlenecks and speeding up development to meet fast-changing business needs.

— Matt Hilbert

June 20, 2018