CI for the Rails Guy (or Gal)

This tutorial was presented at the Agile 2007 Conference: http://thewoolleyweb.com/ci_for_the_web_2.0_guy_or_gal/presentation/ci_for_the_web_2.0_guy_or_gal.pdf. I can do the full follow-along tutorial or prune down to a demonstration, depending on the available time slots.

• No hand waving or omitted steps – hands on, starting from just downloads
• Learn how Continuous Integration is used in a live environment
• Learn about cutting edge testing tools
• Learn all the steps needed to do it for your own project
• Will provide CDs with required tools, so the attendees (or non-attendees!) can try it later without having to download.

• Overview of tools used and download sites
• Demo of setting up CI project from scratch * Installing Rails * Creating a dummy rails app for testing * Installing and running CruiseControl * Writing a dummy Test::Unit test (maybe Rspec) * Hooking up Test::Unit (maybe Rspec) under CruiseControl, seeing it run * Installing JsUnit * Writing a dummy JsUnit test * Hooking up JsUnit under CruiseControl, seeing it run * Writing a dummy Selenium test * Installing Selenium * Hooking up Selenium under CruiseControl, seeing it run
• Advanced Issues/Topics: * Multiplatform * Multibrowser * Farms * Virtualization: One Box, Three Platforms – mac/win/linux * Automate and Test Deployment Process * Test Rollback process! * Configuration Management / Version Control * Auto-tag Green Builds * Automatically pre-create Release Branches * Build ALL active branches under CI * Multiple Libraries/ Projects * Dependencies Among Common Libraries and Projects * Dependency modifications should trigger builds of all dependents * Consistent Tags/Baselines Among Projects * Different Builds for Different Environments: * Development vs Demo/Prod * Publishing Artifacts/ Dependencies: * Deployed (Jars/Gems) vs SCM (svn:externals) * Hackability vs Stability: Fear should not inhibit improvement of common libraries * Optimism vs Pessimism: Do What dependency versions are you deploying to prod? * Suites: * You can have more than one! * It’s all about Feedback * Timely vs Comprehensive * Fast vs Thorough * Commit-Triggered vs Scheduled * Minimize Checkout Time * Get HUGE Dependencies and binaries out of Source Control * RubyGems vs. svn:externals vs. freezing * Metrics * Code Coverage – rcov * Mutation Testing – Heckle * red/green trends * Build Length Trends * Notification * Information Radiator(s) – email, RSS, IM, Growl, Ambient Orb * Random Gotchas / Mantras: * “It’s not easy being Green” * Broken Windows are Bad (“Who cares, it’s always red…”) * False Negatives are Bad * Crying Wolf (“it failed for no reason”) * “Intermittent” failures (but it’s not intermittent after you can reproduce it) * “Works Locally” (is your local environment the same as CI? Which one is Prod closer to???) * You can always “temporarily” disable a test in CI * One disabled test is better than a red CI * False Positives are Bad too – being Green, when return code (echo $?) from some step is not 0 * Browser Settings (auto