Git for Dev and Prod Instance
Hi,
i want to start using a Git Repo for our PSU Instance.
I've set-up everything based on the Docs (Git | Devolutions PowerShell Universal | Product guides & reference) but im unsure now how to use it in a good way.
We have our Prod instance, this is configured to OneWay-Sync, so it will only pull new changes from the main branch.
Our Prod instance has Variables, Schedules, etc. configured too.
Im a bit confused now how to handle Development work. We would need to clone the main branch as a new dev branch, but then all of the Variables are pointing to our Prod Systems (Azure for example). The schedules will run too, which should not as those are pointing to Prod System too.
Is there any more detailed tutorial how to handle this or are there any other people which use this already?
Thanks!
Recommended Answer
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
Michel Audi
All Comments (2)
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
Michel Audi
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
Hi @Michel Audi,
thanks for the detailed reply.
I did not realize that the git Settings added the new option "Available in branch". Now it's clear how to proceed with my setup.