15 January 2019
15 January 2019

The ten habits for highly successful compliant 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. Fines are larger than ever for companies with the introduction of the GDPR, CCPA, SHIELD and other regulations. A data breach can risk your company’s reputation and may lead to outrage from your users, which means they’ll go somewhere else. This could put the 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 I haven’t seen it that much in the wild. If you’re not doing database unit tests, 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.

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

Share this post.

Share on FacebookShare on Google+Share on LinkedInTweet about this on Twitter

Related posts

Also in DevOps

Find out the real state of database DevOps

Database DevOps has been a ‘thing’ for a while now. Introducing practices like version control and continuous integration to database development reduces errors, speeds up deployments, and can hel...

Also in Blog

What learning and development means at Redgate

At Redgate, encouraging personal development in our teams is fundamental to building amazing products.

As well as developing new skills for employees to apply to their current work, personal developm...

Also about Database DevOps

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 lo...

Also about Compliant database DevOps

The Database DevOps Challenges SQL Provision Solves

SQL Provision helps to accelerate the delivery of database updates by enabling an organization to provide database copies, and the right data, to all parts of the deployment pipeline that need it, wit...