The document emphasizes the importance of implementing version/source control for databases alongside application code to reduce risk and improve team collaboration. It outlines best practices for database development, including having dedicated environments for developers, effective communication, and the need for regular commits. The content further discusses the necessity of branching for various development stages and suggests using tools to simplify the process.

1. Get Your Database
Under Control
Steve Jones
Red Gate Software

2. Goals
• Understand the value of version/source control
for databases
• Learn the tools, standards, patterns and best
practices needed to manage a database from
source control
• Identify the necessary flow within a team needed
to develop a database with source control

3. Get in touch
Steve Jones
www.voiceofthedba.com
sjones@sqlservercentral.com
@way0utwest

4. How many of you use version control for
your application code?
C#, ASP.NET, Javascript, VB.NET, etc.

5. How many of you use version control for
your application code?
database

6. Developers who refuse to use source/version
control should be fired, simple as that.

7. Isn’t this too much trouble for my crappy
experimental program?

8. Use source control because neither you
nor your developers are perfect.

9. There are no excuses where
you should not use it.

10. If it’s not in source control,
it doesn’t exist.

11. “…your database should always
be under source control right
next to your application code.”

13. Reducing Risk

14. You’re using version control

15. You’re using version control

16. Use Something

17. Demo
Getting started with databases in VCS

18. Additional Reasons for Source Control
• Backup & Restore
• Undo
• Audit changes
• Sandbox
• Branching/Merging

19. Rules for Database Development
Never use a shared database for development.
Always Have a Single, Authoritative Source
For Your Schema.
Always Version Your Database.

20. The Ideal
• Each developer has a
dedicated environment with
a copy of the schema and
minimal data.
• A shared integration environment where all
developers’ changes are merged, available
for developer testing.

21. Patterns and Practices
• Get all your code
– Object DDL
– Assembly code
– Security grants and revokes
– Database configuration settings
– Jobs for your application
– Lookup data

22. Patterns and Practices
• Commit Early, Commit Often
• Use meaningful comments. Why, not what.
• Check for changes often
• Use common names and code patterns
• Use tools
• Branch Rarely

23. Teamwork

24. Teamwork
• Communication
o Team members need to be aware of (easily)
what others are doing.
• Coordination
o Teams need to work in a way that
complements each other.

25. Teamwork
• Communication
o Review each other’s code as you refactor
o Share knowledge
o Coordination
o Decide on common code styles and names
o And …

26. Teach

27. Demo
The flow within teams

28. Reasons to Branch
• Release
• Hot Fixes
• New Development
• Integration
• Feature set

29. Reasons to Branch
• Release
• Hot Fixes
• New Development
• Integration
• Feature set

30. Demo
Branching

31. Best Practices
• Use version control for all code (including tests)
• Commit early, commit often
• Use tools
o If it’s hard, people don’t do it
• Train people
• Build often

32. Automation

33. Automation
Deployment
package

34. deployment package
1
2
3
FAI
L
Development

35. Goals
• Understand the value of version/source control
for databases
• Learn the tools, standards, patterns and best
practices needed to manage a database from
source control
• Identify the necessary flow within a team needed
to develop a database with source control

36. Thanks for coming
www.voiceofthedba.com
sjones@sqlservercentral.com
@way0utwest
Want to try the tools you’ve just
seen? Come to our Hands-on Labs

37. References
• http://stackoverflow.com/questions/115369/do-you-use-source-control-for-your-
database-items
• http://www.codinghorror.com/blog/archives/001050.html
• http://www.codinghorror.com/blog/2008/02/get-your-database-under-version-
control.html
• http://www.ssw.com.au/ssw/Standards/Rules/RulesToBetterSQLServerData
bases.aspx
• http://odetocode.com/blogs/scott/archive/2008/01/30/three-rules-for-database-
work.aspx
• Check in early, check in often -
http://www.codinghorror.com/blog/2008/08/check-in-early-check-in-often.
html
• http://betterexplained.com/articles/a-visual-guide-to-version-control/

38. Credits
• https://www.flickr.com/photos/doug88888/8
349818088/in/photostream/
• https://www.flickr.com/photos/8525214@N
06/5132974421