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 P4 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 P4 Server infrastructure. Automated build processes frequently access the P4 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 P4 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 P4 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
P4 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.
If you need to upgrade build servers, see Upgrade replica servers.