this is more a conceptual rather than a technical question. In our current project, we maintain two TeamCity installations, one in-house and one on-site at our customer. So far, the two instances have been kept in sync manually, which is an error-prone and cumbersome process. I have recently learned about Kotlin DSL, especially the new portable format introduced in TeamCity 2018.1, which seems to be a perfect fit for our setup. With that format, DSL scripts are supposed to be server and project independent. However, we have dozens of build configurations with environment-specific settings such as host names or API endpoints. Where are we supposed to store these settings?
Obviously, we cannot store them at the project configuration level as they would end up in the DSL script, rendering the entire script non-portable. We also consider configuring all these settings at the root level to be rather impractical, because we have hundreds of different parameters scattered across dozens of project configurations. Moving all settings to the root level sounds like maintenance hell to me, as there is apparently no grouping mechanisms for parameters. We also contemplated the idea of wrapping every versioned project configuration in a non-versioned project that contains the environment-specific parameters for the enclosed project. But given that we have dozens of TC projects, it seems again overly complex.
Are we missing something? Is there an established "best practice" approach towards managing environment-specific settings in combination with portable DSL scripts? Your help is greatly appreciated.