CI Fundamentals

From CitconWiki
Jump to navigationJump to search

Facilitated by Josh Graham

What is CI?

Continuous Integration is a development practice, not a particular technology.

  • Source code management integration
  • Removes repetitive, laborious actions
  • Automated tests?
    • Sometimes
  • Automated builds?
    • Fancy cron job, build scripts
  • Automated deployments?
    • Seldom
  • Standards / Conventions / Metrics
    • Coverage metrics
    • Code style, format
    • Development team metrics
  • Something more ... ?

Continuous Integration

  • Continuous = ALL THE TIME
  • Integration = Combining the changes from all developers
  • When should I check in?
    • As often as possible
    • Make “more often” more possible
  • What should I do before I check in?
    • Shout out, have conversation – especially when you’ve just made cross-cutting or complex changes
    • Is it already broken?
    • Update from SCM repository
    • Pre-commit build
  • How long should it take?
    • As quick as possible
    • Make “more quick” more possible
    • < 10 minutes (this is already painfully long)

What should I do when it breaks?

  • Ignore it?
  • Fix it?
  • Just run it again?
    • Environmental, intermittent perturbations (esp. brittle tests)
  • Rollback?
    • Don’t immediately understand why, or the person who did it has left the building
    • When I didn’t check in for a while and I got "Fabioed" (TODO: jagraham explain)

Fabio was some guy with a habit of refactoring code structure in the evening. Moral of the story was - start each day with a check-out, finish the day with a check-in.

Who owns it?

The “build” is another piece of the software, and requires the same diligence. Who owns it?

  • SCM team?
  • The architect?
  • The build monkey / master?
  • The team?

The room seemed to think "shared ownership" is a good thing, so "The team" seems like a safe choice.

Why should I use it?

  • Pain
    • It’s there. Get it early, often, and in small bits.
    • It just gets worse the longer you wait.
  • Feedback
  • Quality
  • Consultants like me will laugh at you


  • Timer (e.g. 2 hours between check-ins is “too long”)
  • High visibility changes
  • Build pipelining
  • Smoke tests, fragile areas of code
  • When it’s green, do the “slow” build
  • SCM hooks/triggers
  • Format the code to a homogenous style
  • Include story/card/issue/bug number in check-in comments
  • One commit, one change
  • Tests all pass again; reflexive check-in.

Classic blunders

  • Forgot to include the JAR / DLL I just started using
  • Added new class / package and forgot to “Add” in SCM – use IDE integration
  • Abusive check-style rules
  • Deployment process can have a “chicken-and-egg” stage with changes to config for pre-prod/prod environments


  • Lack of team discipline
    • Don’t leave until it’s Green
    • Build blame
    • Dunce, cowboy caps
  • Code size
  • SCM patterns in use (e.g. branching policy, isolation)
  • SCM design (e.g. lack of atomicity, locked file)
  • Application architecture
    • e.g. ability to disable features)
    • The complexity of the build mirrors the complexity of your application
  • Test times
  • Build times
  • Deployment complexity
  • Infrastructure
    • Fastest disks possible
    • Lots-o-RAM
    • Fast network to SCM box

Tools to help?

See Jeff's session