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