Continuous IntegrationBy Ike Ellis@ike_ellis

www.ikeellis.comBlog.ikeellis.com

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

The Integration/Deployment Process

• We do it when we feel like it• 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

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• Jenkins• RedGate CI for databases

CI Disadvantages

• Takes time to setup• You actually have to write tests• Build time should be short. This can take

a lot of effort• Wounded pride

CI 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– So they can get latest

Problems with the database

• Source control has been spotty• Willingness to bug fix in production• Thoughts that indexes are not business logic, and thus

don’t need to be replicated– So dev/test is not the same as production

• Change management has been very difficult– Products often have it wrong

• Writing stored procedure/function/SQL tests have not been the easiest thing to write– Think about comparing values from separate stored

procedures– Test the weather

• Basically, you have to want it and fight for it

Demo

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

Ike Ellis

• http://blog.ikeellis.com• http://www.ikeellis.com• YouTube – http://www.youtube.com/user/IkeEllisData

• SQL Pass Book Readers – http://bookreaders.sqlpass.org/

• San Diego Tech Immersion Group• Twitter: @ike_ellis• 619.922.9801• Email address is just my first name

@ikeellis.com