SQL Server Development Best PracticesSource Control, Testing, and

Continuous Integration

Ike Ellis, MVP

The Monastery

Please silence cell phones

Explore Everything PASS Has to Offer

Free SQL Server and BI Web Events Free 1-day Training Events Regional Event

Local User Groups Around

the World

Free Online Technical Training

This is Community Business Analytics Training

Session Recordings PASS Newsletter

Session Evaluations

ways to access

Go to

passsummit.com/evals

Download the GuideBook App

and search: PASS Summit 2014

Follow the QR code link displayed

on session signage throughout the

conference venue and in the

program guide

Submit by 11:59 PM ESTFriday Nov. 7 toWIN prizes

Your feedback is important and valuable.

Evaluation Deadline:

11:59 PM EST, Sunday Nov. 16

Agenda

• Source Control

• Testing

• SQLCop

• Continuous Integration

• Continuous Deployment

• Tooling

No Developer Left Behind

Time

Main Trunk

New Dev Working

When Integration Time Strikes

Longer Time = More Errors

More errors to solve, means more time to solve errors

Dev continues, prolonging error correcting time

Integration might never happen

Time

Main Trunk

New Dev Working

Shorten the Time

Less or no problems to solve

Deployment can always happen

Code on every workstation is in a build

ready condition

Main Trunk

New Dev Working

• Complicated deployment is always messed up

• Same simple deployment, but hundreds of times (lots of

customers – multitenancy)

Other problems

“Great software developers are 127 times more effective

than average, but only require 50% higher salary, making

them the best bargain in business.”

Martin Fowler

• Change tracking

• Code storage

• Permissions

• History

What is source control?

• Check-in

• Check-out

• Merge

• Branch

• Undo

• Lock

SC: Process

• Management visibility

• Productive developers

• Allows insight into all work done

• Compliance and auditing

• Scalable team

• Code delivery

• History tracking

• Rollback capable

• Safety net

• Allows for danger/manages risk

Source Control: Benefits

Source Control: Products

• Version control is easy with files

• Much harder with a managed database file

SC: Problems with the Database

• Everything’s a file (any product)

• Migrations/file versions/update scripts

• TFS

• Notion of offline, disconnected dev

• RedGate

• ApexSQL

SC: Options

Check in Lookup Table/Data

http://blogs.msdn.com/b/ssdt/archive/2012/02/02/includin

g-data-in-an-sql-server-database-project.aspx

Building CI with TFS

http://blogs.msdn.com/b/ssdt/archive/2014/07/24/sql-

server-database-projects-and-team-foundation-build.aspx

References

Source ControlDemo

• Write code all day…never write a test

• Something breaks

• Cheapest place to find the bug?

Unit Testing: What happens without it

Write a bug QA Testing Deliver

Bug Correction Time

0.85

Find A Bug Fix A Bug

• Automated and self-checked procedure used to validate

that a particular module of source code works correctly

• Write tests for Triggers, Stored Procedures, Functions

Unit Test: What is it?

Arrange

Act

Assert

Unit Test: Process

• Documents code functionality

• Better than commenting code

• Allows refactoring

• Red Green Refactor Repeat

Unit Testing: Benefits

Unit Testing: Main Benefit

Tests get checked in and run regularly

Prevents same bug from happening again

Unit Testing & Source Control

• Unit testing framework for MS SQL Server

• Compatible with SQL Server 2005 and above

• Tests are run inside transaction

• Grouped together in a schema

• Output to text or XML

• Fake tables and views

• Spy on stored procedures

tSQLt

• Supports sproces, functions, and table triggers

• Needs a test project and a SQL test class added to that

project

• Test Explorer

TFS Unit Testing

Tracks SQL Best Practices

Free

Sprocs come with SQLTest

SQLCop

Unit TestingDemo

• Long names = OK

• Test small chunks

• Covering is overrated

• Tests take no arguments

• Not all sprocs are testable, but if testing is what you do,

you’ll write better sprocs

• Test against a different database than development• Insolate yourself from development database changes that rapidly change

Testing Best Practices

CI: The Integration/Deployment Process

We do it when we feel like it

We do it daily

We do it on a schedule

We do it at every check-in to source control

CI: Benefits

• Avoids the “Works on My PC” syndrome

• All developers can get their work deployed and not be left behind

• Tests can be run constantly, and breaking tests can generate emails, thus inspiring code confidence

• Higher quality in code

• Automatically build documentation, remove unneeded files, include dependencies

• Increased visibility of project

• Deployment can be separate from developers

• Easier to deploy dev environment to new developers

CI: Working with Legacy Code

First thing we do is deploy

Can we deploy

Is source control accurate?

CI Fundamentals

Build Steps = Automatically Build Stuff = Scripts

Build Triggers = What makes us build?

Build Agents = What can we do in the CI process?

Build Notifications = Who gets told what and when?

Build Correction = What went wrong and who will solve it?

CI Products

CruiseControl

Hudson

JetBrains = TeamCity

MSBuild/TFS

RedGate CI for databases

CI Process (An Example)

Step 1: Check in from source control

Step 2: Build Trigger begins a build, CI takes over

Step 3: CI builds the solution

Step 4: CI runs all the tests

Step 5: CI deploys package to a UAT server

Step 6: CI notifies everyone a new build is ready to test

Best Practices – Don’t Break the Build

Check-in several times

a day

Merge changes at

every check-in

If you broke the build,

tell everyone, so they

can stop getting latest

from source control

Don’t check-in until

the build is fixed

Notify everyone once

the build is fixed

Continuous IntegrationDemo

• Great for velocity

• Used when it’s a single system with many complicated

parts

• Load balancers

• file servers

• databases

• web services

• Or a simple system, but replicated many times, like multi-

tenancy

• Or both

Continuous Deployment

Continuous DeploymentDemo

Code &

Write TestsCheck-in

Run Tests

& Integrate

Create

Build

Deploy to

UAT

Deploy to

Production

Generic Tools

Database Tools

Visual StudioSubversion

GIT

TFS

TFS(Test & Buid)

TeamCity

Jenkins

CruiseControl Octopus Deploy

SSDT

SSMS

RedGate

ApexSQL

SSDT

tSQLt

RedGate Test

SSDT

SSDT

RedGate

RedGate

• Write tests to avoid errors with missing objects, schema changes,

bad logic, and bad migrations

• Use source control and versioning to create a good migration

• Use CI to create a build that is repeatable and roll-backable

• Every developer should have their own database

• Use CD to control complicated build systems with moving parts, or

repeatable simple build systems, like multi-tenancy

Do what you know you’re supposed

to be doing

Conclusion and Best Practices

Ike Ellis, MVP• http://www.ikeellis.com

• The Monastery

• SQL Pass Book Readers

• San Diego Tech Immersion Group

• @ike_ellis

• 619.922.9801

• Email address is just my first name @the-monastery.com