Difference between revisions of "CI Fundamentals"
From CitconWiki
Jump to navigationJump to search (New page: == What is CI? == * Source code management integration * Removes repetitive, laborious actions * Automated tests? ** Sometimes * Automated builds? ** Fancy cron job, build scripts * Autom...) |
|||
| Line 1: | Line 1: | ||
| − | |||
== What is CI? == | == What is CI? == | ||
* Source code management integration | * Source code management integration | ||
| Line 31: | Line 30: | ||
** Make “more quick” more possible | ** Make “more quick” more possible | ||
** < 10 minutes (this is already painfully long) | ** < 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 | ||
Revision as of 21:30, 27 July 2007
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
