Helix Core Server Administrator Guide: Multi-Site Deployment (2019.1)

Configuring a build farm server

Continuous integration and other similar development processes can impose a significant workload on your Helix server infrastructure. Automated build processes frequently access the Helix server to monitor recent changes and retrieve updated source files; their client workspace definitions and associated have lists also occupy storage and memory on the server. With a build farm server, you can offload the workload of the automated build processes to a separate machine, and ensure that your main Helix server’s resources are available to your users for their normal day-to-day tasks.

Note

Build farm servers were implemented in Helix server release 2012.1. With the implementation of edge servers in 2013.2, we now recommend that you use an edge server instead of a build farm server. As discussed in Commit-edge, edge servers offer all the functionality of build farm servers and yet offload more work from the main server and improve performance, with the additional flexibility of being able to run write commands as part of the build process.

A Helix Core server intended for use as a build farm must, by definition:

  • Permit the creation and configuration of client workspaces
  • Permit those workspaces to be synced

One issue with implementing a build farm rather than a read-only replica is that under Helix server, both of those operations involve writes to metadata:

  • in order to use a client workspace in a build environment, the workspace must contain some information (even if nothing more than the client workspace root) specific to the build environment
  • in order for a build tool to efficiently sync a client workspace, a build server must be able to keep some record of which files have already been synced.

To address these issues, build farm replicas host their own local copies of certain metadata. In addition to the Helix server commands supported in a read-only replica environment, build farm replicas support the p4 client and p4 sync commands when applied to workspaces that are bound to that replica.

If you are auditing server activity, each of your build farm replica servers must have its own P4AUDIT log configured.

Note

For upgrading, see Upgrading replica servers.