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