Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Case study: 13 Common Mistakes Organizations Make With DLM and How to Solve Them

259 views

Published on

Ike Ellis, SQL Server MVP - presentation at SQL in the City
At its most fun, software development is a team sport. Think of an NFL team. Does the quarterback know where the running back or tight-end will be? Does he do his job in a vacuum or with coordination and support from his teammates?
However, if the teammate isn't doing what they're supposed to do, the play dissolves and leads not only to losing a game, but also individual dissatisfaction. Come to this session to learn how to coordinate and communicate as a team, improving individual and overall developer effectiveness.

Published in: Software
  • There are over 16,000 woodworking plans that comes with step-by-step instructions and detailed photos, Click here to take a look ●●● http://ishbv.com/tedsplans/pdf
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • The #1 Woodworking Resource With Over 16,000 Plans, Download 50 FREE Plans... ♣♣♣ http://ishbv.com/tedsplans/pdf
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • The #1 Woodworking Resource With Over 16,000 Plans, Download 50 FREE Plans... ◆◆◆ http://tinyurl.com/y3hc8gpw
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Be the first to like this

Case study: 13 Common Mistakes Organizations Make With DLM and How to Solve Them

  1. 1. 13 Mistakes Common Mistakes Made By SQL Server Developers and how to solve them Ike Ellis, MVP #SQLintheCityUS
  2. 2. They think testing is a waste of time Write a line of code Deliver Code to Users #SQLintheCityUS
  3. 3. #SQLintheCityUS
  4. 4. They refresh their development environment with production data 1. Save Schema 2. Restore Database 3. Reset security 4. Restore Schema #SQLintheCityUS
  5. 5. Why do they do this? • Bugs in production are not reproducible in development • They like seeing real data because it gives them better testing of user interfaces and other things • They like to be able to quickly answer questions #SQLintheCityUS
  6. 6. What’s the downside? • Break tests because of old data • Production data shouldn’t be seen by developers • If development environments are on laptops, laptops get stolen and the company has lost production data • Development servers are not usually backed up or secured properly --And the development database is way too large--- #SQLintheCityUS
  7. 7. The dev environment database is way too large • Why is it large? • 15 years of data • 75% of blob storage – (PDFs, DOCs, AVIs) • Lots of temp files, ETL imports, etc Huge Bloated Database #SQLintheCityUS
  8. 8. Why is that bad? • Database is not portable • Multiple database environments are difficult to setup • Hard to backup • Hard to restore • Hard to rebuild • Hard to obfuscate • Hard to query • Development takes a really long time • Big data costs money to store – big SANs – big developer laptops #SQLintheCityUS
  9. 9. What’s the alternative • All development data is mocked – Tests are repeatable • Thread the buggy data, back through the development process • Write a test that will fail with the new data • Solve the issue • Watch the test pass • Check the test into source control • Run the tests all the time • Bug never happens again I’m mocking your data #SQLintheCityUS
  10. 10. They update production outside of their development pipeline • Changes are fast • Bugs are fixed quickly • The pipeline is too slow to release #SQLintheCityUS
  11. 11. Why is this bad? • Changes don’t get tested • Changes don’t go back into the development environment • Changes can cause table and schema locks and cause unexpected downtime • These changes are often not peer reviewed #SQLintheCityUS
  12. 12. They have three part database names I like to reference you! Oooo, I like to reference you, too! #SQLintheCityUS
  13. 13. Let’s get married! #SQLintheCityUS
  14. 14. But not all marriages are happy… • Creates a tight coupling • Moved together – To a new server • Have to be tested together • Have to be integrated together • Have to change together • Have to be upgraded to a new version • Have to be backed up together • Have to be restored together #SQLintheCityUS
  15. 15. They have four part database names I like to reference you! Oooo, I like to reference you, too! #SQLintheCityUS
  16. 16. Why is this bad? • Servers are now anchored together • It complicates building a test, QA, integration, or canary environment • Security concerns #SQLintheCityUS
  17. 17. Developers share databases • Source control history – Generation 0 – Visual Source Safe – Generation 1 – Subversion, TFS – Generation 2- GIT, Mercurial • Sharing databases is like going back to generation 0. #SQLintheCityUS
  18. 18. They think a rollback plan is undoing a change outside of their development pipeline • You can’t unbake this turkey • You have to fix it • Those fixes need to be tested – run it through again! #SQLintheCityUS
  19. 19. They don’t obfuscate production data in all of their environments I was your data, but now you don’t recognize me
  20. 20. They don’t use a canary If I die, you better not deploy! #SQLintheCityUS
  21. 21. They let more than one application touch a transactional database • Microservices • One application to one database • Change together in the same pipeline • Decouple everything, and I mean everything, else
  22. 22. They don’t build their databases / or they ignore compile errors • Lots of processes, including RedGate CI Server, will do this • Show bad bindings • Show bad columns • Show sprocs that just won’t run • Show tight-coupling #SQLintheCityUS
  23. 23. They write SQL Statements against tables • More coupling #SQLintheCityUS
  24. 24. Ike Ellis • Crafting Bytes – Small San Diego Software Studio – Modern web, mobile, Azure, SQL Server – Looking for future teammates! • Book: Developing Azure Solutions • Podcast Guest: – Talk Python to Me – Dec 2015 – .NET Rocks – Sept 2015 • www.craftingbytes.com • blog.ikeellis.com • www.ikeellis.com • SDTIG – www.sdtig.com Ike Ellis, MVP @ike_ellis 619.922.9801 ike@craftingbytes.com #SQLintheCityUS

×