Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
CONTINUOUS INTEGRATION
        SUCKS
     Please hold the boos til the end.
WHO?

• Ryan   Stenhouse - Rubyist form Fife

• @ryanstenhouse    on Twitter

• HHRy    on GitHub and irc.freenode.net

• ...
WHY DOES CI SUCK?

• Letsyou know things have gone wrong when they are actually
 a problem - already in your SCM.

• Not r...
HOW TO FIX CI

• Make    it useful in a DVCS / DSCM environment.

• Merge    changes form developer repositories

• Check ...
DISTRIBUTED DEVELOPMENT
                         WHERE DOES CI FIT
                            IN HERE?
STAGING          L...
HOW TO FIX IT
STAGING          LIVE            FIXED?

                        By adding a ‘merge’ point
   MASTER / ‘GOLD...
THE INTEGRATION PART
• Foreach developer repository, check it out and run the tests.
 If they pass - Merge them into a ‘ch...
WHAT DO YOU GET?

• A ‘gold’ that   should always be in a deployable state.

•A single developer can’t put broken code int...
THAT’S IT
  Questions?
Upcoming SlideShare
Loading in …5
×

Ci Sucks

1,758 views

Published on

My lightning talk from the Scottish Ruby conference.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Ci Sucks

  1. 1. CONTINUOUS INTEGRATION SUCKS Please hold the boos til the end.
  2. 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. 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. 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. 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. 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. 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. 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. 9. THAT’S IT Questions?

×