Your SlideShare is downloading. ×
Ci Sucks
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.

Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Ci Sucks


Published on

My lightning talk from the Scottish Ruby conference.

My lightning talk from the Scottish Ruby conference.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide

  • Transcript

    • 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 • prawn-graph, gpgr, jobby-rails •
    • 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?