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

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