Solving the dev database problem with GitHub, Docker and PsDatabaseClone

Target Audience:

  • Are you lumbered with a shared “Wild West” dev database? Do you struggle to manage concurrent development tasks?
  • Developers: Is it a pain getting the dev and test environments you need, including realistic and up to date test data?
  • DBAs: Are all these requests for dev and test databases getting in the way of important production work? Are you concerned about prod data leaking into the dev/test domain?

If these problems resonate, this session offers you a practical solution. One that requires collaboration between developers and DBAs – and which benefits everyone.

Abstract:

DevOps promotes self-service access to usable test data – but so many developers are lumbered with shared development databases which are often out of date and contain sensitive data. It’s difficult to isolate the development of different features, so they are rolled together into big releases. It’s no wonder database deployments are often expensive, complicated and risky.

What if it was possible for developers to provision themselves with a disposable, masked copy of last night’s production 64 TB database on either their regular laptop or a shared test server, with limited storage, in a matter of seconds? What if it was as easy as “git clone f5”?

In this session attendees will learn to use GitHub, Docker, SSDT and PsDatabaseClone to unshackle themselves from “Wild West” dev databases and empower them to use modern branching techniques and Azure DevOps to continuously deliver their updates to production.

Why I Want to Present This Session:

I’ve been helping folks to adopt database DevOps since 2010. In my experience, the biggest problem for the vast majority of folks is reliance on a shared development database.

I want you to delete your shared dev database – and never look back.

_________
Image source: Michael Neel, Wikimedia, shared under Creative Commons Attribution 2.0 Generic
https://commons.wikimedia.org/wiki/File:Stormtroopers_march.jpg

 

The following two tabs change content below.
Alex is a Data Platform MVP who loves DevOps. He has been helping data professionals apply DevOps principles to relational database development and deployment since 2010. He's most proud of helping Skyscanner develop the ability to deploy 95 times a day. Originally for Redgate, later for DLM Consultants, Alex has worked with clients on every continent except Antarctica - so he's keen to meet anyone who researches penguins. A keen community member, he co-organises the London Continuous Delivery meetup and SQL Relay. He blogs at workingwithdevs.com, speaks wherever they'll let him and manages the DLM Digest monthly email: a report on the latest database DevOps news/tutorials. He's quite fond of nutella. And otters. (Not together.)
, , , , ,
Previous Post
SQL Admin Best Practices with DMVs
Next Post
Databases 101 for the Aspiring App Dev

4 Comments. Leave new

I would be really interested in this session as we’re struggling with these issues exactly!
However, we still use TFS on-premises at the moment, will that also work with the above approach?

Reply

Hi Nicky, I’m very pleased to hear that!

Yes, should be fine. Are you using a TFGit or a TFVC repo?

I’ll probably spend a bit of time (no a lot) talking about branching and pull requests etc. This will be pretty consistent accross GitHub vs a TFGit repo hosted in a relatively up to date TFS on-prem/Azure DevOps Server instance. The branching stuff will also apply to TFVC repos to some extent, but it’s worth being aware that Git handles branching in a very different (and superior) way to TFVC.

However, with regards to all the Docker/PsDatabaseClone stuff (the meat of the talk) it makes zero difference what source control system you use.

Reply
Eugene Meidinger
September 14, 2019 9:59 am

Phenomenal abstract. You have clear writing that is broken up into multiple paragraphs. You very clearly articulate the pain point and why we should care about your session.

Reply

    Wow, thanks Eugene! Got a bit of constructive feedback along the way from Ed Elliot and Peter Schott, so I can’t take all the credit!

    Reply

Leave a Reply to Alex Yates Cancel reply

Your email address will not be published. Required fields are marked *

Fill out this field
Fill out this field
Please enter a valid email address.

Menu