The document outlines best practices for a highly effective SQL Server development environment led by Ike Ellis of Crafting Bytes, emphasizing code collaboration, the importance of avoiding production data in development, and maintaining small, manageable databases. Key practices include using mocked data for testing, a fast release pipeline to mitigate bugs, and avoiding tightly coupled database references. Additionally, it underscores the need for continuous testing and the risks associated with production updates and data bloat.

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

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

6. They test all of the time…mostly test first
Write a line of code Deliver Code to Users
#SQLintheCityUS

7. #SQLintheCityUS

8. They never code with production data
on a dev server
1. Save Schema
2. Restore Database
3. Reset security
4. Restore Schema
#SQLintheCityUS

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

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

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

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

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

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

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

16. They avoid three part
database names
I like to
reference
you!
Oooo, I like
to reference
you, too!
#SQLintheCityUS

17. Let’s get married!
#SQLintheCityUS

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

19. They avoid four part
database names
I like to
reference
you!
Oooo, I like
to reference
you, too!
#SQLintheCityUS

20. Why is this bad?
• Servers are now anchored together
• It complicates building a test, QA, integration,
or canary environment
• Security concerns
#SQLintheCityUS

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

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

23. They obfuscate production data
in all of their environments
I was your data,
but now you
don’t recognize
me

24. They use a canary
If I die, you
better not
deploy!
#SQLintheCityUS

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

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

27. They write never write SQL Statements against
tables
• More coupling
#SQLintheCityUS

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