KBEC-00465 - CloudBees CD Global Properties - Best Practices

Summary

Properties may need to be used by many projects. Here are some considerations when facing this situation.

Solution

The best practice recommendation for sharing properties across projects within CloudBees CD, is to place those properties into the most appropriate project, and then assign appropiate ACLs for any of the other project(s) that may require access to be referencing or updating those properties.

That said, it is true that there is also a global namespace withing CloudBees CD, which lies under the /server path.

Using property sheets under /server can give you the equivalent of creating what might be traditionally thought of as a “Global Variable”, but of course, this generates all the natural concerns that “Global Variables” can create (open and uncontrolled access being the biggest risk). 
So we recommend that you use this namespace sparingly or do so with a defined plan in place so that all your developers are aware of the intent for this action.  

As with most “quick solutions”, using a global namespace may allow you to get moving on some information sharing actions quickly, but these may get out of hand if you don’t put intention behind your plans. 
We’ve seen a few customers end up with 1000s of properties in this way.

NOTE - We would not recommend placing properties directly at the /server level, although nothing prevents you from doing so. 
If you do intend to use this space, then as a best practice it would be recommended that you create a property sheet, or a tree of property sheets (as required) to make it easier to remove/cleanup specific sub-spaces at some future time. 
You will notice that property sheets are being used in this namespace OOTB for various purposes and plugins within the product already, so you should watch out to not step on top of these, as these may change with version updates in the future.

As identified in the documentation, Change Tracking is strongly encouraged to be de-activated for particularly high-churning projects, but the de-activation of Change-Tracking for the global namespace is an all-or-nothing selection. 
(See the bottom of this page for how to deactivate non-project data :  https://docs.cloudbees.com/docs/cloudbees-cd/latest/change-tracking/ctperformance)
If you end up with large volumes of variables in the /server space, then you may find an excessive amount of Change Tracking history being stored as a result. 
Also note that de-activating this option will also remove CT data for things like resources or other system content, so creating excessive properties in this space may eventually create a conflict for you and is another reason to encourage using Projects to place such properties instead.

Please also review the content of this page for Change Tracking best practices in general:  https://docs.cloudbees.com/docs/cloudbees-cd/latest/change-tracking/ctbest-practices