CI Fundamentals

From CitconWiki
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 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