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.

11 Goals of High Functioning SQL Developers

3,081 views

Published on

This session focuses on what it takes to be high-functioning SQL developers in a world of continuous delivery and continuous integration.

Published in: Software
  • Be the first to comment

  • Be the first to like this

11 Goals of High Functioning SQL Developers

  1. 1. 11 Goals A portrait of a highly functioning SQL Server development shop Ike Ellis, MVP Crafting Bytes A San Diego Software Studio #SQLintheCityUS
  2. 2. Two pairs of eye on all SQL code, minimum – sometimes 3 or 4 • They pair minimum • Sometimes they mob • This allows for someone to do the right thing • And they can slack and work
  3. 3. They don’t give estimates • They work off of a prioritized list and deliver a piece of value every day to the organization • They let the organization change anything on the list, except the first three things • You get it when it’s ready
  4. 4. They test all of the time…mostly test first Write a line of code Deliver Code to Users #SQLintheCityUS
  5. 5. #SQLintheCityUS
  6. 6. They never code with production data on a dev server 1. Save Schema 2. Restore Database 3. Reset security 4. Restore Schema #SQLintheCityUS
  7. 7. Why do they do this? • Bugs in production are not reproducible in development • They like seeing mock data because it gives them better testing of user interfaces and other things • They like to be able to quickly answer questions #SQLintheCityUS
  8. 8. 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
  9. 9. What do they do instead? • All development data is mocked – Tests are repeatable – They use MOQ/Xunit – But you can easily use tSQLt/RedGate SQL Test, instead • 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. The dev environment database is stays very small • 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 Tiny Dev Database
  11. 11. What’s wrong with data bloat? • 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
  12. 12. They never update production outside of their development pipeline • Changes are fast • Bugs are fixed quickly • All because they’re release pipeline is very fast #SQLintheCityUS
  13. 13. What’s wrong with updating production servers? • 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
  14. 14. They avoid three part database names I like to reference you! Oooo, I like to reference you, too! #SQLintheCityUS
  15. 15. Let’s get married! #SQLintheCityUS
  16. 16. 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
  17. 17. They avoid four part database names I like to reference you! Oooo, I like to reference you, too! #SQLintheCityUS
  18. 18. Why is this bad? • Servers are now anchored together • It complicates building a test, QA, integration, or canary environment • Security concerns #SQLintheCityUS
  19. 19. Developers have their own database • 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
  20. 20. They avoid rollback plans. Instead, they keep changes inside 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
  21. 21. They obfuscate production data in all of their environments I was your data, but now you don’t recognize me
  22. 22. They use a canary If I die, you better not deploy! #SQLintheCityUS
  23. 23. They never 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
  24. 24. They build their databases and they fix 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
  25. 25. They write never write SQL Statements against tables • More coupling #SQLintheCityUS
  26. 26. 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

×