What is the Server Deployment Package (SDP)?

Supported Open Source Software

When deployed or certified by Perforce Consulting, the core functionality of the SDP is officially supported by Perforce Support, except for files in the Unsupported directory tree.

The Unsupported folder included with the SDP is community supported, but officially supported by Perforce Support. (Unsupported files were in various folders prior to the 2020.1 release.)

The SDP is open source software (see the LICENSE), and accepts contributions (pending code review) from the user community.

Please see the doc directory for:

• SDP_GUIDE.Unix PDF version, HTML version, or ASCIIDoctor version
• SDP_GUIDE.Windows PDF version, HTML version, or ASCIIDoctor version
• SDP_Failover_Guide PDF version, HTML version, or ASCIIDoctor version

High Availability (HA)

The SDP supports a variety of methods for achieving high availability that benefit simple, single-server environments and sophisticated global enterprise environments, and all in between. Standardized and documented recovery procedures, offline databases, and optional replication (made easier with the SDP) all make HA easier to achieve.

There is more detailed discussions and references in the SDP Guides noted above.

Disaster Recovery (DR)

Just as with HA, the SDP makes it easier to implement robust, reliable DR strategies.

There is more detailed discussions and references in the SDP Guides noted above.

Fast and Safe Upgrades

The SDP makes upgrades of Helix server products fast and easy, regardless of the scale of your environment. By taking advantage of the offline database structure, the SDP enables upgrades with just a few minutes of downtime (enough to do a journal rotation).

Production Focus

The p4d executable, without any configuration, is optimized for evaluation and demonstration purposes. While it has many features that can make it reliable and robust, many of those features must be configured. The SDP is intended to be used for production environments or more realistic Proof of Concept installations.

See the Helix Installer which makes quick work of installing the SDP for PoC evaluation with a production-like setup, complete with the Sample Depot training data set.

Best Practice Configurables

The SDP also maintains, on an ongoing basis, a set of best-practices configuration settings (e.g. 'configurables' and environment settings) suited to production environments, which often differ from p4d defaults.

Optimal Performance, Data Safety, and Simplified Backup

The SDP provides a standard structure for operating Perforce that is optimized for performance, scalability, and ease of backup. The SDP Guide includes documentation that promotes volume layout and storage architecture best practices.

To simplify backup, all digital assets are in a single directory. Live databases that cannot be backed up live in another, and active log files in another. For any scale environment, this makes it easy to back up the server's critical data. For larger scale environments, these directories become storage volume mount points, with the layout promoting best performance and data safety.

Sophistication Simplified

In addition to the basics, the SDP provides structure, standards, guidance, and automation that greatly simplify deployment and management of sophisticated Helix global topologies. For example, the SDP includes tools that greatly simplify complex tasks such as creating new replicas, backing up edge servers without down time, etc.

Multi-Instance Management

The SDP supports operation of multiple instances of Helix on a machine, allowing each instance to have differing configuration, e.g. different:

• versions of software components (p4d, p4broker, etc.)
• case sensitivity setting (sensitive/insensitive)
• Unicode setting (enabled/disabled)

Shell Environment Management

The SDP provides standard mechanism for defining a controlled shell environment. This benefits p4d and other Perforce software products directly, and also provides good examples of controlling the environment for supporting automation.

Perforce Automation Standards

The SDP defines a standard for installing and configuring derived APIs. For example, Python is built with P4Python in /p4/common/python, and Perl with P4Perl in /p4/common/perl.

Stock vs. Custom SDP

Many Perforce customers use the SDP as-is. Others benefit by incorporating concepts and ideas from the SDP into their own environments, e.g. for development of custom policy enforcement triggers, systems integrations, promoting or enforcing local naming conventions, etc.

Helix Management System

The Helix Management System (HMS) is a separate, community-supported product that builds on the SDP. This is likely to be of interest at installations with sophisticated global topologies and/or a fleet of SDP instances to manage.

Bugs, Enhancements, and Future Plans

Perforce Jobs are used to file bugs and request enhancements to the SDP. The list of jobs (other than closed ones) can be viewed here.

You can see all jobs (including closed ones if desired) from the command line interface. Connect to The Workshop and run the <code>p4 jobs</code> command, something like this:

p4 jobs -l -e "Project=perforce-software-sdp ^Status=closed"

While there is currently no formal roadmap for the SDP, it is actively maintained and continues to evolve alongside P4D and other Helix Core components it manages. Jobs are occasionally reviewed and addressed as time allows for consultants and contributors, sometimes driven by customer-funded consulting projects.

Contributing

Contributions to the SDP are most welcome! Note that contributing requires a basic user knowledge of working with Perforce.

Contributing by Shelving (Small Changes)

For contributing small changes, contribute by shelving changelists to the 'dev' branch your workspace.

All registered Workshop users have open access (but not write) to the SDP dev branch. This allows shelving (but not submitting) updates to the SDP dev branch path:

//guest/perforce_software/sdp/dev/...

To contribute by shelving, create a workspace that maps that path, named something like 'your_user.your_hostname.sdp'. Make your changes in that workspace, provide a good changelist description, and include a <code>#review</code> tag in your changelist description.

When you are ready, shelve the changelist. Perforce Consultants will review the change, and either incorporate it or provide feedback. Be sure to provide a detailed change description, and don't forget include the <code>#review</code> tag in your changelist description to initiate a Swarm pre-commit code review.

Contributing by Branching (Bigger Changes)

Optionally, you may also branch the SDP dev branch, or some subset of it, into your own guest area. Creating a branch spec is recommended for this purpose, e.g. with a branch spec like this:

Branch: your_name-sdp

Owner: your_name

Description:
    SDP Updates by your_name.

Options:    unlocked

View:
    //guest/perforce_software/sdp/dev/.. //guest/your_name/sdp/dev/...

If you branch a subset, maintain the full path structure (as in the example above), so you can easily expand the scope of what you branched initially at some later date.

Edit, test and submit changes in your branch. Keep your code up to date with other changes by merging down from the shared dev branch to your dev branch, e.g. by doing:

p4 merge -b your_name-sdp

... followed by the usual resolve and submit.

When you'e ready to copy your versions up to our dev branch, do like so:

p4 change
p4 copy -c YourCL -r -b your_name-sdp

Be sure that your changelist has a clear and accurate description, and that the description contains a <code>#review</code> tag on a line by itself. That will trigger a code review process when you shelve the change, like so:

p4 shelve -c YourCL

Perforce Consultants will review the change, and either incorporate it or provide feedback. Be sure to provide a detailed change description, and don't forget include the <code>#review</code> tag in your changelist description to initiate a Swarm pre-commit code review.

Guidelines for SDP Contributors

• Communicate! Use Swarm or email! Let folks know what you're planning before you work too hard on something that might already be underway.
• File a job (Project=perforce-software-sdp) first. That's not required, but increases the transparency of what you're doing, and helps promote it.
• We prefer changes that are generic, and have a wide appeal.
• The core of the SDP, the scripts that do offline checkpoints for p4d, prioritize Perforce best practices over scripting magic. Don't get too fancy! :)

Versioning the SDP Locally

You may want to version the SDP locally. See the SDP Guide for basic versioning instructions.

Optionally, sophisticated enterprise installations may want to use the "Tight Ship" style of management, to be in line with the "Version Everything" mindset. For more info, see the Helix Management System (HMS).

Upgrading Older Existing SDP Installations

See the SDP_Upgrade_Guide.Unix

The Windows SDP

There are two flavors of the SDP, Unix and Windows. Both are available from the SDP downloads folder.

SDP Code Quality

An automated regression test suite and pre-commit code review processes help ensure code quality. This is supplemented by manual testing in the Battle School training lab environment. Contact Perforce Consulting for more information.

See more details about the test suite in the Test Suite README file.