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

Binding workspaces to the build farm replica

At this point, there should be two servers in operation:

  • a master server named master, with a server ID of master-1666
  • a build-server replica named buildfarm1, with a server ID of builder-1667
  1. Bind client workspaces to the build farm server.

    Because this server is configured to offer the build-server service, it maintains its own local copy of the list of client workspaces (db.domain and db.view.rp) and their respective have lists (db.have.rp).

    On the replica server, create a client workspace with p4 client:

    $ p4 -c build0001 -p builder:1667 client build0001

    When creating a new workspace on the build farm replica, you must ensure that your current client workspace has a ServerID that matches the ServerID required by builder:1667. Because workspace build0001 does not yet exist, you must manually specify build0001 as the current client workspace with the -c clientname option and simultaneously supply build0001 as the argument to the p4 client command. See the Support Knowledgebase article on "Build Farm Client Management".

    When the p4 client form appears, set the ServerID: field to builder-1667. If the ServerID is not set manually, it will be set automatically when the form is saved.

  2. Sync the bound workspace.

    Because the client workspace build0001 is bound to builder-1667, users on the master server are unaffected. However, users on the build farm server are not only able to edit its specification, they are able to sync it:

    $ export P4PORT=builder:1667
    $ export P4CLIENT=build0001
    $ p4 sync

    The replica’s have list is updated, and does not propagate back to the master. Users of the master server are unaffected.

In a real-world scenario:

  • your organization’s build engineers would re-configure your site’s build system to use the new server by resetting their P4PORT to point directly at the build farm server. Even in an environment in which continuous integration and automated build tools create a client workspace (and sync it) for every change submitted to the master server, performance on the master would be unaffected.
  • performance on the master is likely to improve for all users because of the reduction of read and write operations on the master server’s database.

If there are database tables that you know your build farm replica does not require, consider using the -F and -T filter options to p4 pull. Also consider specifying the ArchiveDataFilter:, RevisionDataFilter: and ClientDataFilter: fields of the replica’s p4 server form.

If your automation load exceeds the capacity of a single machine, you can configure any number of additional build farm servers.