Difference between revisions of "CI Fundamentals"
From CitconWiki
Jump to navigationJump to searchLine 77: | Line 77: | ||
* Abusive check-style rules | * Abusive check-style rules | ||
* Deployment process can have a “chicken-and-egg” stage with changes to config for pre-prod/prod environments | * 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 |
Revision as of 21:33, 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
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