Information Technology Reference
In-Depth Information
developer puts the latest changes from the version control repository
onto her development machine, ensures all tests and inspections run
successfully, and that the database is successfully rebuilt with test data.
This also means each developer should have a “sandbox” in her envi-
ronment that runs the same processes that the integration build runs.
The most important principle to understand is that you should
prevent
the larger builds from failing,
and this means following a process to
integrate and verify all changes with your own build capabilities
before
committing changes to the version control repository. Figure 4-8 dem-
onstrates the steps involved in running a private build before commit-
ting changes to the repository.
“We can't afford a separate build machine.”
Hardware is cheap when compared to the amount of time that can be
lost when an integration problem occurs
.
It doesn't have to cost you a
lot of money. As indicated earlier in this chapter in Bill and Peter's
conversation, you can find an unused computer as your build machine
at first. Then, after the team experiences the benefits of fully integrated
builds, you can invest money in a more capable machine. Without a
separate build machine, you'll also spend time attempting to diagnose
a problem only to discover that a file had not been committed to the
version control repository. That took time, and time is money. Do your
best to put your “sales hat” on and convince management that it will
Build Script
4
Run “Integration Build” Locally
1
Check Out Code from Repository
3
Get Changes from Repository
5
Commit Code to Repository
Developer
2
Make Source Code Changes
Version Control
Repository
FIGURE 4-8
Running a private build to reduce integration build errors
