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

Ci Sucks

on

  • 1,508 views

My lightning talk from the Scottish Ruby conference.

My lightning talk from the Scottish Ruby conference.

Statistics

Views

Total Views
1,508
Views on SlideShare
1,408
Embed Views
100

Actions

Likes
0
Downloads
4
Comments
0

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

Accessibility

Categories

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.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
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?