Continuous Integration

By Ike EllisThe Monastery

@ike_elliswww.the-monastery.comBlog.the-monastery.com

http://www.linkedin.com/in/ikeellis

The Integration/Deployment Process

• We do it when we feel like it– Non-repeatable– We don’t know what we do– We just work until the bugs are gone…and then

we go home• We do it daily• We do it on a schedule• We do it at every check-in to source control

Continuous Integration Means No Developer Left Behind

Time

Main Trunk

New Dev Working

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

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

Working with Legacy Code

• First thing we do is deploy• Can we deploy• Is source control accurate?

CI Fundamentals

• Source Control

Source Control Products

• TFS• Subversion• Git• Mecurial• Perforce

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 Products

• CruiseControl• JetBrains = TeamCity• MSBuild/TFS• RedGate CI for databases

CI Physical Architecture

Dev Environment UAT EnvironmentProduction

EnvironmentCI CI

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 copies data to a UAT server• Step 6: CI notifies everyone a new build is

ready to test

CI Best Practices

• Check-in several times a day• Merge changes at every check-in• Don’t break the build (Get latest, merge, build,

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

The Problem with Databases

• Source Control/Versioning• Merging Changes• Tests• Change Management• Scripting Changes• Continuous Integration

Red Gate Solves Those Problems

• SQL Developer Bundle• Continuous Integration:– http

://www.red-gate.com/products/sql-development/automation-license-for-continuous-integration/

• SQL Source Control– http://www.red-gate.com/products/sql-developm

ent/sql-source-control/webinars

Demo

• TeamCity• Red Gate CI/Team City Integration• Red Gate database source control

Ike Ellis

• The Monastery• http://blog.the-monastery.com• http://www.the-monastery.com• YouTube• SQL Pass Book Readers• San Diego Tech Immersion Group• @ike_ellis• 619.922.9801• Email address is just my first name @the-

monastery.com.