Stephanie Herr

10 February 2023

2 Comments

The ten habits for highly successful end-to-end Database DevOps

Database DevOps has come of age. Now seen as a key technical practice which can contribute to the successful implementation of DevOps, it stops the database being a bottleneck and makes releases faster and easier.

Conversely, perhaps, the automation and audit trails it introduces can help to protect personal data within databases and make compliance part of the same process rather than an additional time-consuming step outside it.

That said, to implement it successfully, there are ten areas which teams should focus on.

Have DBAs on the team

DevOps is all about breaking down the silos between different teams and working together to deliver value to users. Developers and DBAs have a lot to learn from each other and both skillsets are extremely important.

By having DBAs on the team, problems can be avoided or found sooner, before they get to Production and affect users. This will hopefully reduce the Us vs Them mindset and the conflicts that usually arise between Developers, who want to release changes quickly, and DBAs who need to maintain the security and stability of Production. Instead, the team can work together on operational concerns like security, stability and performance from the beginning.

Have the team aligned on a common goal

It’s all about the value that the business is delivering to the user. If we all understand our users better, then we’ll appreciate why the work is important and what affect it might have. While working towards a common goal, it also helps to focus on small increments to reduce risk, learn, and improve as you go, and concentrate on building quality in.

Protect your data

This is key for DBAs and businesses and ultimately Developers. Beyond regulations like the CCPA, HIPAA, and the GDPR, a data breach can risk your company’s reputation and may lead to outrage from your users, which means they’ll go somewhere else. For example, McKinsey’s 2022 Global Digital Sentiment Survey shows that consumer trust in digital channels has declined by six percentage points since 2021, and concerns about how data is handled, along with cyberattacks, top the list of trust issues. This could put any business at risk, which ultimately jeopardizes the jobs of DBAs and Developers.

Access to realistic Production data during development and testing, however, is always the preferred route and helps find issues or performance problems sooner, a concept known as shifting left. Teams need to have this capability while still protecting the sensitive data in Production by, for example, using masking and pseudonymization techniques.

Backups, high availability, and good disaster recovery processes are also important to protect your data.

Standardize

Agree on naming conventions, documentation levels (I like to describe my tables and columns in extended properties), code styles (SELECT vs select), and tools (using Git across all projects, for example). This will help people moving between teams and provide consistency. Instead of just agreeing on them, try to put things in place to encourage following them, or use a tool that can apply proper styles to make it easier.

Version control your database code

Version controlling your database code is important because it gives a history of changes being made to the database, which provides security and a starting point for rolling back any breaking changes. Working in a dedicated database sandbox also allows teams to make changes quickly without affecting others. Version control is the best way to share database changes between developers and it’s also the starting point for any kind of Continuous Integration, Continuous Delivery, and/or Continuous Deployment processes.

Automate your releases

With your database in version control, continuous integration and automated release processes can be put in place. This streamlines releases, which removes bottlenecks and reduces manual errors. This is incredibly important for teams that need to release more often.

Always test your release in a Staging or Pre-Production environment

Releasing to Production shouldn’t be the first time the deployment script is tested. Instead, it should be tested along the way in CI, Test, QA, and/or UAT environments. It’s incredibly important to have a final release test on an environment (sometimes referred to as Staging or Pre-Production) that is as close as possible to your Production environment, to help identify any issues reaching Production which might affect your users.

Automate your tests

In order to release more frequently, you need to have automated tests so that you’re confident in what’s being released. Database unit testing is possible, but if you’re not doing that, then hopefully the database is being tested as part of the entire application in automated integration or systems testing. I would highly recommend at least having some smoke tests for your database that cover the most critical parts, and building testing into your database development processes as you go forward.

Monitor

Monitoring is important because it lets you find out about issues or potential issues before your users do and fix them fast. Downtime is incredibly costly, so you also need to be able to understand the causes of any such database performance issues quickly. It’s nice to see when a release happened which may have caused a problem, for example, so that you can track down the root cause sooner. This can easily be done with an automated release process which provides an audit trail of when releases occurred and what changes were made.

It’s also good to monitor changes that happen outside of your release process, often called database drift. Why did this happen? Was it a valid Production hot fix or a user without proper permission accessing Production? If valid, how do you make sure the changes are reflected in your earlier environments so that you’re testing against a more realistic production version and they’re not overwritten with the next release?

Celebrate successes

Being part of a team that is doing DevOps well is an incredible experience. You’ll release changes more frequently and learn as you go how to improve the experience for your users. You may find some things don’t work or you need to pivot, but you’ll be able to get back on track quickly.

You’ll also find some great successes as you get your database into version control and start automating releases, and these occasions should be celebrated. DevOps is about people, processes and tools working together, and it’s the people part that’s the most important. So celebrate and then share your successes with others to help them on their DevOps journey as well.

If you’d like to know more about how the database can be included in DevOps, you might like to read Enabling digital transformation – and data modernization – with DevOps. Written by Pramod Sadalage, a Director at Thoughtworks, it talks about the mindset that enables DevOps, the typical pitfalls organizations face, and where data comes into the picture.

To find out more about Redgate’s compliant database DevOps approach, visit the solutions pages.

This blog post was updated on January 10, 2022