Difference between revisions of "CI Fundamentals"
From CitconWiki
Jump to navigationJump to searchLine 1: | Line 1: | ||
+ | Facilitated by Josh Graham | ||
+ | |||
+ | |||
== What is CI? == | == What is CI? == | ||
* Source code management integration | * Source code management integration | ||
Line 55: | Line 58: | ||
* Quality | * Quality | ||
* Consultants like me will laugh at you | * 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 | ||
+ | |||
+ | |||
+ | == 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 |
Revision as of 21:31, 27 July 2007
Facilitated by Josh Graham
What is CI?
- 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)
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?
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
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