Information Technology Reference
In-Depth Information
Keep Builds in the “Green”
I find that there are two measures of using CI effectively: number
of commits and build status. Each developer (or pair) should have
at least one commit to the repository per day, and the number of
checkins usually demonstrates the size of the changes (more
commits usually means smaller changes—and this is good). Your
build status should be “green” (pass) a large percentage of the
day; set this value for the team. We all get a “red” build status
sometimes, but what's important is that it's changed back to green
as soon as possible. Never let your team get used to waiting in the
red status until this or that other project task is done. The willing-
ness to leave the status at red for other criteria defeats much of
the strength of CI.
When the build is broken, don't check out the latest code from the ver-
sion control repository. Otherwise, you must spend time developing a
workaround to the error known to have failed the build, just so you can
compile and test your code. Ultimately, it's the responsibility of the
team, but the developers responsible for breaking the build
should
already be working on fixing their code and committing it back to the
version control repository. Sometimes a developer may not have seen
the e-mail on the broken build. This is when a passive feedback mech-
anism such as a light or sound can be useful for colocated developers.
We consider it critical that all developers know the state of the code in
the version control repository. For more information on continuous
feedback mechanisms, see Chapter 9. An alternative, but not preferable,
approach to avoiding a checkout is to use the version control system to
roll back any changes since the most recent commit.
❑❑❑❑❑❑❑❑❑
