[p4] Perforce and continuous integration (XP)
steve at vance.com
Thu Jul 12 18:05:33 PDT 2001
Except for controlling the flow of source between projects, sub-projects,
etc., Perforce proper has not been instrumental in this for me.
What has worked best for me has been to mirror the hierarchy of components
in the architecture in the test framework. A test module applies to each
component. The test component has a dependency on the component that it
tests, and test components have dependencies on the test components of
their corresponding modules dependencies. Therefore the primary build
object is a test framework and everything below a particular point gets
built as a consequence. The test component not only builds its tests but
runs them. The policy in this case is that successful tests are silent,
unless run in a special logging mode, and only failed tests complain and
stop the build.
Therefore, every developer build of a particular component builds and tests
its compatibility with its dependencies. Coupled with policies that
require full builds before submit, this covers most of it.
If you also want independent builds, you can run a similar builds from a
Perforce review daemon or from a cron/scheduler job in either full or
incremental modes, depending on your product build time and your level of
concern about mistaken submissions.
In general I've found that the peer pressure of a bad submission that syncs
to everyone else is more effective (without artificial amplification) than
infrastructure instrumentation at keeping things in line.
At 02:50 PM 7/10/2001 +0100, Tony Robinson wrote:
>How are people using Perforce to meet the needs of continuous integration,
>as promoted for example by Extreme Programming?
>perforce-user mailing list - perforce-user at perforce.com
mailto:steve at vance.com
More information about the perforce-user