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 22: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