What is the 'best practice' GIT setup for a Prod / Dev environment?

PowerShell Universal
1 
Product: PowerShell Universal
Version: 4.1.8

Good Morning all, hope everyone is having a good day!

I am trying to setup git sync between a production and dev instance using the PSU in-built sync but all the documentation focuses only on Github / Remote repos.

What I am trying to do is setup a production instance that pushes certain configs back to the dev instance (Ignoring things like auth.ps1 etc) as well as allowing me to push changes from the dev instance to the production instance manually.

Currently the production and dev instances are not ā€˜linkedā€™ at all (This is another aspect of the documentation that confuses me. It mentions ā€œattaching an instance to the databaseā€ but nowhere does it tell you how to do that as far as I can find.). At the moment Iā€™m manually making any changes in my dev instance to make it match the production instance and then manually copying any changes back from dev to production and re-configuring all the paths, variables, creds, etc etc.

How is this designed to be used so we can have a dev instance that can push changes to a production instance as well as pull certain configs from production? Are we expected to do what I mentioned above and manually copy / edit the code between the two instances?

I guess to sum it up, ignoring what is being asked for now, how are we MEANT to be utilizing this feature properly?

Any advice would be greatly appreciated!

1 Like
2

Iā€™m not sure how things are meant to be done, but I can try to detail what I do, which does require a remote Git repository. For starters, as I said in the PowerShell Discord on this topic, I donā€™t use Git sync with the database.

The Git Setup

  1. Create a Git repository containing the contents of the $env:ProgramData\UniversalAutomation\Repository folder.
  2. Create a new branch from main called dev.
  3. Host that repository on a web service accessible to the PSU server (I use CodeCommit, but GitHub would be much easier).
  4. Install Git on the PSU server, because this method requires an external Git client.
  5. Configure Git credentials:
    1. Ummā€¦ I forgot how I did this, and I didnā€™t document it. Iā€™m probably doing something weird, because itā€™s CodeCommit.
    2. This should help you, though: https://docs.powershelluniversal.com/config/git#setting-credentials
  6. Add $env:ProgramData\UniversalAutomation\Repository as a safe folder in your Git configuration:
    git config --global --add safe.directory "$env:ProgramData/UniversalAutomation/Repository"

PSU Git Settings

  1. Configure Git Settings as follows:
    • Remote: <path to my remote repository>
    • Branch: main
    • Sync Behavior: One-Way
    • Sync Interval: 10
    • Use External Git Client: True
    • Mode: Automatic
    • Bundle Git Repository in Database: False
  2. Configure it the same in your dev environment:
    image
    image798Ɨ447 16.7 KB

Generalize the environment

To create variables I can use in places like authentication.ps1, I borrowed this trick from @mikedhanson Setup environment-specific variables in PSUHeader

For secrets, I use the PSUSecretStore vault for those variables in my variables.ps1 file like this:
New-PSUVariable -Name "MyApiKey" -Vault "PSUSecretStore" -Type "System.String"
Then I set the secrets through the web UI. This kind of sucks when youā€™re destroying the environment frequently.

Caveats, etc.

  • The biggie: Your web UI basically becomes read-only. I think the only things you can change through the UI are Git settings and secret values.

  • You and anyone else working on PSU kind of have to learn how to use Git. Itā€™s a great tool to have in your toolbelt, but itā€™s not simple.

  • I donā€™t like working with a dev and main branch, but you might not have to. For me, itā€™s the only way I could come up with to put a ā€œreview gateā€ before deploying to production without the overhead of a release pipeline. In my case, changes to main have to be approved in CodeCommit. If you donā€™t have that same need, you can configure Git settings in your production environment for Manual synchronization. Then you can use a trunk-based development strategy, and only sync production after you have things working in dev.

  • Sometimes, variables created in the PSUHeader region get duplicated (unless thatā€™s been fixed recently).

  • In the future, I might switch to pulling secrets from our external secret store so I donā€™t have to reset them in PSU when I rebuild the environment.

I know thatā€™s not exactly what youā€™re askin for, but thatā€™s how Iā€™m doing a dev environment.

6 Likes
3

Hi guys!
I am very new to PSU. Currently I am in a testing phase for implementation of PSU, but I do not really know (and maybe it is a stupid question) do I need separate databases (SQL) for prod and dev instances?
So an example would be: 3 instances for production environment do have 1 common sql database, 4 instances for development need another common sql database?
We do also have a gitlab server in the company and would use that to implement main and dev branches. So prod and dev environments could be connected to that server to the correct branches.
Am I correct or completely wrong?

Thanks in advance

4

Hi Patrick,

You will need a separate database for each instance.

My devops environments are a mix of SQLite dbā€™s and Azure SQL databases depending on if the instance is a dev test or prod db.