Hi Simon,
Thank you for the clear description of your setup. Yes, there is guidance for it: the Git page has a Branching Strategies section for this layout. A separate dev instance, with its own database and scheduler, runs against a dev branch, while production pulls main one-way. Changes reach production when you merge dev into main. Each instance needs its own license.
https://docs.devolutions.net/powershell-universal/config/git/#branching-strategies
The order matters for your two concerns.
Schedules: first, before you create the dev branch and connect the dev instance, add -AvailableInBranch 'main' to each New-PSUSchedule line that must only run in production, in .universal\schedules.ps1 on main, and commit (the One-Way console is read-only). PSU then runs such a schedule only on an instance synced to main; a schedule with no branch set runs everywhere. These schedules also no longer appear in the dev console, so edit them in schedules.ps1.
https://docs.devolutions.net/powershell-universal/automation/schedules
Variables: on the dev instance, tick Store In Database on the variables that differ between dev and prod (or -Database with New-PSUVariable), and set the dev value. The repository then holds only the definition, and each instance keeps its own value in its own database.
When that change reaches production, the variable is empty there until you set it with the Set Variable Value button, which stays available in One-Way mode, so set it right after the sync. Secret values sit in the vault, not the repository, so they also differ per instance when each instance has its own vault, such as the Database vault.
https://docs.devolutions.net/powershell-universal/powershell-commands/new-psuvariable
https://docs.devolutions.net/powershell-universal/platform/variables/
Other users describe the same dev/prod layout on our forum (on an older version):
https://forum.devolutions.net/topics/54183/development-flow
Best regards,
Michel
