Configuring a build server (also known as 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 buiild server, you can offload the workload of the automated build processes onto a separate machine. This ensures that your main Helix server’s resources are available to your users for their normal day-to-day tasks.

If your automation load exceeds the capacity of a single build server, you can configure any number of additional build servers. The term "build farm" typically implies more than one build server.

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

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

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

• to use a client workspace in a build environment, the workspace must contain some information specific to the build environment, such as the client workspace root.
• for a build tool to efficiently sync a client workspace, a build server must be able to keep a record of which files have already been synced.

To address these issues, build servers host their own local copies of certain metadata. In addition to the Helix server commands supported in a read-only replica environment, build servers 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 servers must have its own P4AUDIT log configured.