Please hold the boos til the end.
• Ryan Stenhouse - Rubyist form Fife
• @ryanstenhouse on Twitter
• HHRy on GitHub and irc.freenode.net
• prawn-graph, gpgr, jobby-rails
WHY DOES CI SUCK?
• Letsyou know things have gone wrong when they are actually
a problem - already in your SCM.
• Not really compatible with distributed development and SCM
- very SVN-dependant workﬂow
• Doesn’t really ‘integrate’ anything.
• Should probably be part of your staging deployment process
HOW TO FIX CI
• Make it useful in a DVCS / DSCM environment.
• Merge changes form developer repositories
• Check them against your current known-good ‘gold’ repository
• Check that the new code has adequate coverage versus the
• Then pull it into your ‘gold’ as good code.
WHERE DOES CI FIT
No one logical place,
there are three possible
entry points for bad
MASTER / ‘GOLD’
code into your Master,
and that’s what you
DEV1 DEV2 DEV3 deploy to Staging and to
HOW TO FIX IT
STAGING LIVE FIXED?
By adding a ‘merge’ point
MASTER / ‘GOLD’ before master and gold,
you can automate so
ACTUALLY much of your quality
INTEGRGATE control and build it right
into your deployment
DEV1 DEV2 DEV3 strategy
THE INTEGRATION PART
• Foreach developer repository, check it out and run the tests.
If they pass - Merge them into a ‘check’ repo / branch
• Test the ‘check’, run its suite. If it fails, reject the merge.
• Diff the ‘check’ against the ‘gold’. Examine the differences
(with Rcov tweaks), to ensure the changed parts have
adequate test coverage.
• Integrate into ‘gold’ the non-broken code for distribution to
WHAT DO YOU GET?
• A ‘gold’ that should always be in a deployable state.
•A single developer can’t put broken code into your live
application very easily.
conﬁdence that your application is as robust as
you can measure with tests.
part of a regular deployment schedule - actual