What is the right mix of practices and tools for introducing CI

From CitconWiki
Revision as of 14:17, 22 August 2008 by Mandersn (talk | contribs) (rv to Revision as of 20:54, 31 October 2007 by User:Jtf)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigationJump to search
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

Facilitated by Jeff Frederick

What pain will they address?

  • Expensive (latent) release cycles
    • Make it easier to do what I want to do
    • Spend less time doing mundane activities
  • Engage in higher-value activities rather than repetitive manual tasks
  • Remove some obstacles to communication and collaboration
    • Increase happiness
    • Overcome “culture of blame”
    • Accountability and empowerment
  • Improve visibility and assurance of code quality
    • Sense of accomplishment
    • More confidence / courage
    • Reduce need to re-write due to lack of knowledge / hit-by-bus
    • Ship more often, happier customer, underpants gnomes PROFIT!

Where do I start

  • Recognise we have a problem
  • Consensus on what the problems are and that we want to change
  • Identify the outcomes we would like to have
  • Listen & understand how the issues impact others
  • Change behaviours
    • Empathetic, trust-building
    • Pick some easy wins to build momentum
    • May make it feel worse before it gets better
    • Frequent retrospectives (perhaps daily)
    • Talk to each other (across teams). Brown bags, socialise, catch up over lunch
    • Co-located cross-functional team
    • Light-hearted embarrassment tokens / achievement awards
  • Measurements
    • “Tasks completed each period” (e.g. Stories per iteration)
    • Look at valuable quantitative metrics (e.g. Cyclomatic complexity)
  • Code reviews
    • Set the context for positive outcome – it’s not for the mob-flaming of the code author or their skills
    • Impromptu: “Hey there, whatchya doin?”
    • Ask questions to understand design intent
    • Ask someone to look at yours
    • Have the strong developers demonstrate good examples for others to learn from
    • Knowledge sharing
  • Don’t fall for overly-draconian style rules early on

Tools

To Start

  • The Basics
    • Unit tester (e.g. JUnit)
    • Builder (e.g. Ant)
    • CI server (e.g. CC)
    • Coverage (improving trend)
    • Change notification
    • “Basic” code consistency checks
  • Consistent code
    • Jalopy
    • Checkstyle
    • IntelliJ inspections
  • Change set notification, review tools
    • SCM commit triggers
    • FishEye
    • RSS
  • Coverage
    • Clover, Cobertura
    • Emma

Later

  • “Problematic code” detection
    • Findbugs
    • Google singleton collector
    • Complexian, Jeff’s “Crap4J”
    • Simian
    • PPMD
  • Test veracity
    • Agitator
    • Jester
  • What files are being changed by others?
    • Crucible
    • Conflict
  • Profiling, performance tuning
    • JProbe, etc