CI Fundamentals

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

Tips

• 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

Inhibitors

• 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