unit tests - (pg 60) - test small pieces of your application in isolation; they run without starting the whole application
component tests - (pg 60) - test the behavior of several components of your application; they may hit the database, filesystem, or other systems (which may use stubs); Component tests typically take longer to run than unit tests.
Acceptance tests - (pg 60) - test that the application meets the acceptance criteria decided by the business in terms of behavior, security, and performance; Acceptance tests run against the whole application in a production-like environment
Hard Prerequisites
Version Control - Anything needed to create, install, run, and test your application
Automated Build - Able to "start your build" from the commandline
Agreement of the Team - "Continuous integration is a practice not a tool"
Implementation
First Steps
Check in Regularly
smaller changes
less conflict
need to integration to practice continuous integration
Comprehensive automated test suite
Unit, component, and acceptance tests
Should proved "an extremely high level of confidence"
Short build
"ten minutes is about the limit, five minutes is better, and about ninety seconds is ideal"
two stages: "commit" and...unnamed stage in which acceptance tests run
commit stage runs for every checkin
acceptance stage runs after commit stage (not clear if this is gating)
incorporate smoke tests into commit stage
Development workspace
Must be managed
should be able to run same test and deployment
management of 3rd party deps
CI Systems
Basics
Long runnning process at intervals
View the result after a run
aside: This section seems to be describing cron
Bells and Whistles
Dashboards: builds status + avatars
"Visibility is one of the most important parts of a CI server"
source code analysis
coverage
duplication
standards
cyclomatic complexity
Cultural Shifts for CI
Don't check-in a broken build
Run all tests before check-in
Wait for tests to pass before moving on
Never go home on a broken buildbroken beta
Always be prepared to revert
Time-box fixing before reverting
Don't comment out failing tests
Take responsibility for breakage
TDD
Distributed Teams
Process
Everyone available remotely
Centralized Continuous integration
makes it easy to self-serve
makes it easy to gather standard metrics
Distributed VCS
has an additional layer of indirection before checkin