Build server

You can offload the workload of the automated build processes onto a separate machine. This machine is a build server, and if you use multiple build machines, you might call them a build farm.

Using one or more build servers ensures that the resources of your main Helix Core Server (or servers) are available to your users for their normal day-to-day tasks.

Continuous integration and other similar development processes can impose a significant workload on your Helix Core Server infrastructure. Automated build processes frequently access the Helix Core 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.

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 Core 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 Core 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.