Post on 14-Apr-2017
11 GoalsA portrait of a highly functioning SQL Server development shop
Ike Ellis, MVPCrafting Bytes
A San Diego Software Studio
#SQLintheCityUS
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
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
They test all of the time…mostly test first
Write a line of code Deliver Code to Users
#SQLintheCityUS
#SQLintheCityUS
They never code with production data on a dev server
1. Save Schema2. Restore Database3. Reset security4. Restore Schema
#SQLintheCityUS
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
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
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
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
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
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
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
They avoid three part database names
I like to reference
you!
Oooo, I like to reference
you, too!
#SQLintheCityUS
Let’s get married! #SQLintheCityUS
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
They avoid four part database names
I like to reference
you!
Oooo, I like to reference
you, too!
#SQLintheCityUS
Why is this bad?• Servers are now anchored together• It complicates building a test, QA, integration,
or canary environment• Security concerns
#SQLintheCityUS
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
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
They obfuscate production data in all of their environments
I was your data, but now you
don’t recognize me
They use a canaryIf I die, you better not
deploy!
#SQLintheCityUS
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
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
They write never write SQL Statements against tables
• More coupling
#SQLintheCityUS
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_ellis619.922.9801ike@craftingbytes.com
#SQLintheCityUS