Successfully reported this slideshow.
Your SlideShare is downloading. ×
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad

Check these out next

1 of 9 Ad
Advertisement

More Related Content

Similar to Ci Sucks (20)

Advertisement

Recently uploaded (20)

Advertisement

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?

Editor's Notes










×