Information Technology Reference
In-Depth Information
Now you have the ammunition to go talk to others about CI. This chap-
ter covered some of the basics of CI, discussed how to get to a contin-
uous process, and pointed out all the other areas that get explored in
detail in subsequent chapters. Table 2-1 summarizes seven practices
to follow when using CI. The next chapter delves into the software
risks that CI can help mitigate to improve quality.
CI Practices Discussed in This Chapter
TABLE 2-1
Practice
Description
Commit code frequently
Commit code to your version control repository
at least once a day.
Don't commit broken
code
Don't commit code that does not compile with
other code or fails a test.
Fix broken builds
immediately
Although it's the team's responsibility, the devel-
oper who recently committed code must be
involved in fixing the failed build.
Write automated
developer tests
Verify that your software works using automated
developer tests. Run these tests with your auto-
mated build and run them often with CI.
All tests and inspections
must pass
Not 90% or 95% of tests, but
all
tests must pass
prior to committing code to the version control
repository.
Run private builds
To prevent integration failures, get changes from
other developers by getting the latest changes
from the repository and run a full integration
build locally, known as a private system build.
Avoid getting broken
code
If the build has failed, you will lose time if you get
code from the repository. Wait for the change or
help the developer(s) fix the build failure and
then get the latest code.
Practicing CI is more than installing and configuring some tools. How
many of the following items are you consistently performing on your
project? How many of the other CI practices can improve your devel-
opment capabilities?
