This deck describes how to unit test, source control, and put a SQL Server database into a continuous integration/ continuous deployment environment.

1. SQL Server
Development Best
Practices
Source Control, Testing, and
Continuous Integration
Ike Ellis, MVP
The Monastery

2. Please silence
cell phones

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

4. 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 EST
Friday Nov. 7 to
WIN prizes
Your feedback is
important and valuable.
Evaluation Deadline:
11:59 PM EST, Sunday Nov. 16

5. Agenda
• Source Control
• Testing
• SQLCop
• Continuous Integration
• Continuous Deployment
• Tooling

7. No Developer Left Behind
Time
Main Trunk
New Dev Working

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

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

10. • Complicated deployment is always messed up
• Same simple deployment, but hundreds of times (lots of
customers – multitenancy)
Other problems

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

12. • Change tracking
• Code storage
• Permissions
• History
What is source control?

13. • Check-in
• Check-out
• Merge
• Branch
• Undo
• Lock
SC: Process

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

15. Source Control: Products

16. • Version control is easy with files
• Much harder with a managed database file
SC: Problems with the Database

17. • Everything’s a file (any product)
• Migrations/file versions/update scripts
• TFS
• Notion of offline, disconnected dev
• RedGate
• ApexSQL
SC: Options

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

19. Source Control
Demo

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

21. Bug Correction Time
0.85
Find A Bug Fix A Bug

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

23. Arrange
Act
Assert
Unit Test: Process

24. • Documents code functionality
• Better than commenting code
• Allows refactoring
• Red Green Refactor Repeat
Unit Testing: Benefits

25. Unit Testing: Main Benefit

26. Tests get checked in and run regularly
Prevents same bug from happening again
Unit Testing & Source Control

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

28. • Supports sproces, functions, and table triggers
• Needs a test project and a SQL test class added to that
project
• Test Explorer
TFS Unit Testing

29. Tracks SQL Best Practices
Free
Sprocs come with SQLTest
SQLCop

30. Unit Testing
Demo

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

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

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

34. CI: Working with Legacy Code
First thing we do is deploy
Can we deploy
Is source control accurate?

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

36. CI Products
CruiseControl
Hudson
JetBrains = TeamCity
MSBuild/TFS
RedGate CI for databases

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

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

39. Continuous Integration
Demo

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

41. Continuous Deployment
Demo

43. Code &
Write Tests
Check-in
Run Tests
& Integrate
Create
Build
Deploy to
UAT
Deploy to
Production
Generic Tools
Database Tools
Visual Studio
Subversion
GIT
TFS
TFS(Test & Buid)
TeamCity
Jenkins
CruiseControl Octopus Deploy
SSDT
SSMS
RedGate
ApexSQL
SSDT
tSQLt
RedGate Test
SSDT
SSDT
RedGate
RedGate

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

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