Information Technology Reference
In-Depth Information
A dangerous assumption on a project is that everyone knows not to
commit code that doesn't work to the version control repository. The
ultimate mitigation for this risk is having a well-factored build script
that compiles and tests the code in a repeatable manner. Make it part of
the team's accepted development practice to always run a private build
(which closely resembles the integration build process) before com-
mitting code to the version control repository. See the later section,
Run Private Builds, for additional recommendations before commit-
ting your code.
A
broken build
is anything that prevents the build from reporting suc-
cess. This may be a compilation error, a failed test or inspection, a
problem with the database, or a failed deployment. When operating in
a CI environment, these problems must be fixed immediately; fortu-
nately, in a CI environment, each error is discovered incrementally and
therefore is likely very small. Some projects have a penalty for break-
ing the build, such as throwing some money in a jar or placing the pic-
ture of the last developer to break the build on the company's large-
screen monitor (just kidding; hopefully no one is doing this). The
project culture should convey that fixing a broken build is a top project
priority. That way, not just some but every team member can then get
back to what they were doing.
A build should be fully automated. In order to run tests for a CI sys-
tem, the tests must be automated. Writing your tests in an xUnit frame-
work such as NUnit or JUnit will provide the capability of running
these tests in an automated fashion. Chapter 6 provides details on writ-
ing automated tests.
