1. USING CI & CD WITH MICROSOFT SQL SERVER Tim Giorgi Senior Software Developer Northwest Evaluation Association tim.giorgi@nwea.org @TimGiorgi

2. AGENDA  Deployments Poll  Goals  Terminology  Database Challenges  Tools  Components – What do you need?  Nwea Examples

3. DEPLOYMENT POLL

4. COMPETING GOALS?  Developers: Functional Releases  What this often means:  Long Release Cycles  No Production Ownership - “throw it over the wall” mentality  System Engineers & DBAs: Reliability  What this often means:  Complex Deployment Plans  Rollback Steps  Off Hours Deployments

5. TERMINOLOGY

6. CONTINUOUS INTEGRATION

7. CI BEST PRACTICES  Use a code repository Use a code repository  Automate the build Automate the build  Make the build self-testing Make the build self-testing  Everyone commits to the baseline every day Everyone commits to the baseline every day  Every commit (to baseline) should be built Every commit (to baseline) should be built  Keep the build fast Keep the build fast  Test in a clone of the production environment Test in a clone of the production environment  Make it easy to get the latest deliverables Make it easy to get the latest deliverables  Everyone can see the results of the latest build Everyone can see the results of the latest build  Automate deployment Automate deployment

8. CONTINUOUS DELIVERY

9. CD BEST PRACTICES  Repeatable and reliable  Automate everything!  If something is difficult or painful, do it more often  Build quality in!  Everybody has responsibility for the release process.

10. CONTINUOUS DEPLOYMENT

11. CD BEST PRACTICES  Repeatable and reliable  Use the same processes used for Continues Delivery  Done means “released”  Improve continuously

12. DATABASE CHALLENGES  Deploy Schema Differences  Data Changes  Server Level Changes  Tests change the state of the system!

13. DEPLOYING SCHEMA DIFFERENCES  Two Options:  Change-script-driven approach  Scripts to migrate from one version of the schema to the next are kept in source control, and are only ever run once.  Model-driven approach  Define the desired state of your database. During deployment, a tool compares the model with the actual target database (Data Tier Application or DAC)

14. DATA CHANGES  Custom Scripts  DAC Post-Deployment Scripts  Problems with both: Re-entrancy

15. SERVER LEVEL CHANGES  Logins, Server Configuration  Same answers:  Custom Scripts  DAC – Server Level

16. STATE CHANGES  Snapshots  Transactions w/ Rollback  Database Restores (Empty Schema?)

17. COMPONENTS  Virtual Environments  Source Control System  Build System  Testing System  Deployment System

18. TOOLS Puppet

19. MICROSOFT RELEASE MANAGER

20. PUPPET

21. CHEF

22. OCTOPUS DEPLOY

23. DLM DASHBOARD (SQL LIGHTHOUSE)

24. NWEA – “IN THE WILD”

25. NWEA COMPONENTS  Virtual Environments: vCloud, vCenter  Source Control System: Git & Stash  Build System: Jenkins & SSDT  Testing System: Jenkins & Nunit  Deployment System: Jenkins & Powershell