Microsoft SQL Server Continuous Integration
8 likes6,279 views
The document provides a guide on implementing continuous integration (CI) for SQL Server database development using Jenkins and Redgate tools. Key topics include versioning databases, automating deployments, and running unit tests, emphasizing the benefits of improved efficiency and reduced manual tasks. It also outlines prerequisites, software used, and considerations for successful implementation.
Microsoft SQL Server Continuous Integration
- 1. SQL Server Continuous Integration Using Jenkins and Red Gate Ernest Hwang Principal Software Engineer, Practice Fusion Presented to the Silicon Valley SQL Server User Group May 2013
- 2. Who am I? • Ernest Hwang, Principal Software Engineer at Practice Fusion in San Francisco • C#, .NET, SQL Server Developer • Working with SQL Server since 1999 (SQL Server 6.x) • Using Red Gate for Continuous Integration since June 2011 • Someone who got tired of maintaining a folder of database scripts for every release.
- 3. Why am I here? • To show how easy it is to apply CI principals to Database Development
- 4. What’s this? A “How To” guide for automating your day-to-day maintenance tasks by… • *Easily* Versioning your database using Red Gate SQL Source Control • Using Continuous Integration (via Jenkins) to validate Database builds • Using Jenkins to automate database deployments • Using CI / tSQLt / SQL Test to run unit tests
- 5. Prerequisites • Experience with source control management systems (svn, TFS, git, Hg) • Familiarity with Continuous Integration Products (Jenkins, Team City, Cruise Control) • Awareness of build scripting languages (ant, MSBuild)
- 6. What software is used? • SQL Server 2008 / 2012 • Red Gate SQL Source Control • Red Gate SQL Compare • Red Gate SQL Data Compare • Jenkins Continuous Integration Server http://jenkins-ci.org/ – Promoted Build Plugin – Copy Artifacts Plugin – Version Plugin – Git Plugin • MSBuild
- 7. What is SQL Source Control? • Source Control Plug in for SQL Server Management Studio • Creates a “snapshot” of the database schema defined by CREATE scripts • Snapshot is consumable by SQL Compare and may be used to compare against the schema of an actual database
- 8. What is SQL Source Control? SQL Source Control is to SSMS as TortoiseSVN is to Windows Explorer
- 9. Demo Environment GitHub Local Copy of RGDemo database Dev, QA, & Prod Databases Developer Workstation Build and Database Server (Windows Azure VM)
- 10. Committing Changes to Source Control Demo Local Database Changes Commit Changes via SQL Source Control Changes committed to SCM repository
- 11. How does Continuous Integration fit in? • The CI server polls the repository for changes • When changes are checked in, the CI job kicks off – Verifies that the database can be built • Builds a brand new database from scratch using SQL Compare and SQL Data Compare – Runs unit tests • Build should fail if unit tests do not succeed – Archives the artifacts (for deployments) • Artifacts can include build/test reports – Emails engineers if there are problems
- 12. Breaking the Build Demo Commit Changes via SQL Source Control CI Server Detects Changes Kicks off Build Process Build can pass or fail validation
- 13. Deploying Changes to Different Environments • The Promoted Builds plug in can be used to deploy changes to Integration/QA/Staging/Production environments • SQL Compare and SQL Data Compare are used to deploy changes between the sourced controlled database and your development environments • Deploying to Production and/or Staging can be configured to just create the scripts as opposed to forcing the synchronization
- 14. Deploying to Dev / QA Demo SQL Source Control Repository SQL Compare Development Environment Database
- 15. Creating a Database “Version” • Make sure the Jenkins Versioning plugin is installed • Create a User Defined Function called dbo.DATABASE_VERSION() • Create a build step that updates the UDF with the version number • The updated UDF will be archived and used with deployments
- 16. Versioning your Database Demo Commit Changes via SQL Source Control CI Server Detects Changes Kicks off Build Process Build Task updates dbo.DATABASE_VERSION() Function Updated UDF Archived
- 17. Unit Testing with tSQLt and SQL Test • tSQLt is an open source set of stored procedures and functions to facilitate Unit Testing in SQL databases • SQL Test is a wrapper around this framework that integrates with SSMS • Your build server can enforce that your unit tests pass and generate reports
- 18. Unit Testing with tSQLt / SQL Test Demo Commit Changes via SQL Source Control CI Server Detects Changes Kicks off Build Process Build Task executes Unit Test procedures Tests can pass or fail the build
- 19. What did SQL Source Control do for us? • Saves developers time (yay!) – No more maintaining update scripts – Don’t need to deploy scripts when QA needs changes • Identifies holes in your deployment process – Are developers making changes directly to production? – Are indexes/constraints missing from your Dev/QA/Prod environments? • Creates a definitive database build that can be easily deployed and redeployed
- 20. Considerations • Environments must be pristine • Process must be changed and understood • Production change scripts should be scrutinized (especially for the first few releases) • Migration Scripts can be used to massage data • DB Replication requires more work for promotions
- 21. Appendix 1: Other CI Servers • Jenkins (open source) • Team City (JetBrains) • Bamboo (Atlassian) • CruiseControl / CruiseControl.NET (open source)
- 22. Appendix 2: Other Source Control Systems • Subversion (SVN) • Git • Team Foundation Server • Mercurial (Hg) • AccuRev • Surround SCM
- 23. Links / Contact Info • [email protected] • @ernestedcode • https://github.com/CF9/Databases.RGDemo • Practice Fusion is Hiring (email me) http://practicefusion.com/careers/ • facebook.com/practicefusion • @practicefusion