Scap3 allows two basic ways of configuration: through special sections inside scap.cfg and using the --environment command line argument. For example, the EventBus proxy HTTP service uses --environment to specify a different list of target nodes. On the other hand, Citoid, e.g., specify those inside a beta-specific scap.cfg block:

[deployment-prep.eqiad.wmflabs]
git_server: deployment-tin.deployment-prep.eqiad.wmflabs
server_groups: default
dsh_targets: betacluster

The --environment way of doing it is more elegant, but its drawback is that one needs to add that switch when invoking deploy in deployment-prep. Ideally, one should launch the deploy on both BetaCluster and production in the same way. To achieve that, I propose to allow Scap3 to have environment-specific scap.cfg overrides. The idea is to have the environment configuration option in scap.cfg, so that it prompts Scap3 to look for further configuration in environment/<environment-name>/scap.cfg. In the case of Citoid, the main scap.cfg would then contain:

[deployment-prep.eqiad.wmflabs]
environment: beta

Two files would be placed in environment/beta: betacluster, which contains the list of target nodes in BetaCluster, and scap.cfg with the same contents as before:

git_server: deployment-tin.deployment-prep.eqiad.wmflabs
server_groups: default
dsh_targets: betacluster

Note that those should be overrides, so any unspecified parameter must be taken from the main scap.cfg configuration file.

As far as configuration files and their variables go, the current --environment functionality should be kept. The TL;DR point here is that specifying environment: env-name ought to work exactly in the same way as passing --environment env-name on the command line does.