This document discusses how continuous integration (CI) can be improved to better support distributed development environments. It proposes merging changes from developer repositories into a "check" repository before integrating them into a "gold" repository. The "check" repository would be tested to ensure changes do not break existing functionality. Changes passing these tests would then be integrated into the "gold" repository, keeping it in a deployable state. This approach aims to provide confidence that no single developer can easily introduce broken code into the live application and better facilitates continuous integration as part of regular deployments.

1. CONTINUOUS INTEGRATION
SUCKS
Please hold the boos til the end.

2. WHO?
• Ryan Stenhouse - Rubyist form Fife
• @ryanstenhouse on Twitter
• HHRy on GitHub and irc.freenode.net
• prawn-graph, gpgr, jobby-rails
• http://ryanstenhouse.eu

3. 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 workflow
• Doesn’t really ‘integrate’ anything.
• Should probably be part of your staging deployment process

4. 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
‘gold’
• Then pull it into your ‘gold’ as good code.

5. DISTRIBUTED DEVELOPMENT
WHERE DOES CI FIT
IN HERE?
STAGING LIVE
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
Live.

6. 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

7. 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
staging.

8. 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.
confidence that your application is as robust as
• Increased
you can measure with tests.
part of a regular deployment schedule - actual
• As
Continuous Integration

9. THAT’S IT
Questions?