Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

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

258 visualizaciones

Publicado el

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.

Publicado en: 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
       Responder 
    ¿Estás seguro?    No
    Tu mensaje aparecerá aquí
  • The #1 Woodworking Resource With Over 16,000 Plans, Download 50 FREE Plans... ♣♣♣ http://ishbv.com/tedsplans/pdf
       Responder 
    ¿Estás seguro?    No
    Tu mensaje aparecerá aquí
  • The #1 Woodworking Resource With Over 16,000 Plans, Download 50 FREE Plans... ◆◆◆ http://tinyurl.com/y3hc8gpw
       Responder 
    ¿Estás seguro?    No
    Tu mensaje aparecerá aquí
  • Sé el primero en recomendar esto

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

×