Information Technology Reference
In-Depth Information
• Lengthy integration phases before delivering the software inter-
nally (i.e., test team) or externally (i.e., customer), during which
time nothing else got done
• Inability to produce and reproduce testable builds
Scenario: “It Works on My Machine”
There can be many reasons why a project team is unable to create
working, deployable software: Anything from failing tests to the
wrong files applied to the version control repository can contribute to a
failed build. Here's one such scenario.
John (Technical Lead):
We're having a problem with the latest build
on the test server.
Adam (Developer):
That's funny; it was working when I built it on my
machine. Let me see… Yeah, it's still working.
John:
Oh, I see the problem. You didn't commit your new files into
the Subversion repository.
Solution
We cannot overemphasize the importance of eliminating tight coupling
between your IDE and your build processes. Use a separate machine
solely for integrating the software. Ensure that everything you need to
build the software is contained in the version control repository.
Finally, create a CI system. Use a CI server such as CruiseControl
along with an automated build using tools such as Ant, NAnt, or Rake.
CruiseControl watches for changes in the version control repository
and runs the project build script when it detects a change to the reposi-
tory. You can increase the capabilities of this CI system to include hav-
ing the build run through tests, perform inspections, and deploy the
software in the development and test environments; this way you
always have working software.
Scenario: Synching with the Database
If you are unable to recreate your database quickly during develop-
ment, you will find it difficult to make changes. Often this is due to a
