Builds
A good build environment is essential to XP teams. Constant refactoring, collective code ownership, and ever-changing pair programming teams require that each developer have the ability to reliably build the software using an identical configuration. If this is not the case, then tests that pass for one developer may fail for everyone else.
Continuous Integration
Continuous integration means that XP teams build the software application frequently, often several times per day. In fact, the Cruise Control tool (mentioned in Chapter 1) performs a complete build of the application after every check-in to version control.
After you and your programming partner have finished a task, you should integrate your changes with the shared source code repository. This means that you check in your changes to your version control tool, run a complete build, and run all of the unit tests. If any tests fail, you fix them right away.
Since you probably build your application many times per day, you won’t have any trouble when it comes time to deliver a build to your customer. For this task, you might want to define a script that copies the latest build to a “stable” build directory of some sort. This gives the customers a stable playground from which to run and test the application while the programmers continue with their day-to-day coding and builds.
There is no reason why automated builds should not go all the way to a customer deliverable. For example, if you are building a shrink-wrap product, ...
Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.
Read now
Unlock full access