Get Your Database Under Control

Download Get Your Database Under Control

Post on 15-Nov-2014




3 download

Embed Size (px)


Developers dont even question the need for source control as part of their application life cycle management. But DBAs and database developers just dont look at their databases in the same way as code. However, if you want to get good coordination between your application code and database, if you want to start to automate your database deployments, you need to treat your database like code. This session will demonstrate different mechanisms for getting a database into source control in order to begin to control your database in the same way you control your code.


<ul><li> 1. Grant Fritchey | Red Gate Software Team-based Development with Version Control </li></ul> <p> 2. Get in touch Grant Fritchey @gfritchey 2 3. 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 4. HOW MANY OF YOU USE VERSION CONTROL FOR YOUR APPLICATION CODE? C#, ASP.NET, Javascript, VB.NET, etc. 4 5. HOW MANY OF YOU USE VERSION CONTROL FOR YOUR APPLICATION CODE? database 5 6. Developers who refuse to use source/version control should be fired, simple as that. 6 7. Isnt this too much trouble for my crappy experimental program? 7 8. Use source control because neither you nor your developers are perfect. 8 9. There are no excuses where you should not use it. 9 10. If its not in source control, it doesnt exist. 10 11. your database should always be under source control right next to your application code. 11 12. 12 13. Reducing Risk 13 14. Youre using version control 14 15. Youre using version control 15 16. Use Something 16 17. GETTING STARTED WITH DATABASES IN VCS Demo 17 18. Additional Reasons for Source Control Backup &amp; Restore Undo Audit changes Sandbox Branching/Merging 18 19. Rules for Database Development 19 Never use a shared database for development. Always Have a Single, Authoritative Source For Your Schema. Always Version Your Database. 20. Dedicated or Shared Databases? 20 21. Shared databases are not wrong 21 22. 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. 22 23. Naming Standards Usually vary by company ISO 1179 Be consistent Use tools for enforcement (SQLCop) Document these lightly and JIT 23 24. Style Standards Vary by individual Make code more readable. Use tools to re-format code to your liking. SQL Prompt SSMS Tools Pack Others 24 25. Teamwork 25 26. Teamwork Communication Team members need to be aware of (easily) what others are doing. Coordination Teams need to work in a way that complements each other. 26 27. THE FLOW WITHIN TEAMS Demo 27 28. Automation is Best 28 29. Use Automation Development systems and tools need to work for the team, not against them. Many IDEs and tools work well in team environments, if you configure them. 29 30. Get All Your Code Object DDL Assembly code Security code Configuration settings Jobs Lookup data 30 31. AUTOMATION Demo 31 32. Best Practices Use version control for all code (including tests) Commit early, commit often Use tools If its hard, people dont do it Train people Build often 32 33. Automation 34. Automation deployment package 35. deployment package 1 2 3 Back to Development FAIL FAIL FAIL 36. References your-database-items control.html ases.aspx database-work.aspx Check in early, check in often - 36 37. 37 A big thank you to our sponsors Gold Partners Silver &amp; Track Partners Platinum Partners 38. 38 A big thank you to our sponsors Gold Partners Silver &amp; Track Partners Platinum Partners 39. Get in touch Grant Fritchey @gfritchey 39 </p>