ALM Best Practices with a SQL Server Database
-
Upload
ike-ellis -
Category
Technology
-
view
465 -
download
0
Transcript of ALM Best Practices with a SQL Server Database
SQL Server Development Best PracticesSource Control, Testing, and
Continuous Integration
Ike Ellis, MVP
The Monastery
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
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
• 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
• 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
• 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
• 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?
• Documents code functionality
• Better than commenting code
• Allows refactoring
• Red Green Refactor Repeat
Unit Testing: Benefits
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
• 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 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 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
• 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
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