• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Ci Sucks

Ci Sucks



My lightning talk from the Scottish Ruby conference.

My lightning talk from the Scottish Ruby conference.



Total Views
Views on SlideShare
Embed Views



6 Embeds 100

http://ryanstenhouse.eu 56
http://www.ryanstenhouse.eu 22
https://www.linkedin.com 9
http://www.linkedin.com 8
http://dev.ryanstenhouse.eu 4
http://www.lmodules.com 1



Upload Details

Uploaded via as Apple Keynote

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />

Ci Sucks Ci Sucks Presentation Transcript

  • 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 • prawn-graph, gpgr, jobby-rails • http://ryanstenhouse.eu
  • 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
  • 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.
  • 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.
  • 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 staging.
  • 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
  • THAT’S IT Questions?