[p4] Perforce and continuous integration (XP)

[Stephen Vance]

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.

Steve

At 02:50 PM 7/10/2001 +0100, Tony Robinson wrote:
>Hi,
>
>How are people using Perforce to meet the needs of continuous integration,
>as promoted for example by Extreme Programming?
>
>tony
>_______________________________________________
>perforce-user mailing list  -  perforce-user at perforce.com
>http://maillist.perforce.com/mailman/listinfo/perforce-user

Stephen Vance
mailto:steve at vance.com
http://www.vance.com/