Succeeding with PowerShell Universal Git Sync


This is a companion discussion topic for the original entry at https://blog.ironmansoftware.com/powershell-universal-git-sync/
1 Like

Nice, we are currently looking into 3.x migration. Really appreciate the external git glient support and through that support for ssh which is an enabler for us. We already use git to update our environment in 2.x but have to rely on manual git pull.

1 Like

Hi all, Adam,

Thanks for your post on the Git integration in PSU, we are currently struggling a bit finding a good workflow.
TBH: We’re a small IT team (internal IT, mostly a Windows shop in a on prem VMWare environment) that just started with PSU, and don’t have too much experience with Git either.

I’ll try to give you a brief overview, any feedback regarding our setup is very welcome here.

We recently set up a internal git server as well as a dedicated Windows Server for our PSU instance.
This instance is (as suggested) running as a service, to be able to execute jobs as other users (defined in Secret Variables).

With our PSU license, we generated developer keys to deploy the software on our own workstations, to have a local test/dev environment.

We created a git repo which is synced in Two-Ways (manual mode - external git client) with our production PSU instance (main branch)
On our own workstations we also set up the same git sync, syncing with a “development” branch. (Might switch to a per-feature branch to avoid more problems)

We found out having many sync issues, since the config files used by PSU are also synced between our workstations, as well as when we’re merging our changes into the main branch.
For example:

  • Different settings between production and dev servers (for example a clear “development” AdminConsoleLogo in our local instance, in the /.universal/settings.ps1 file , as opposed to the company logo in our production instance) - so we cannot push some files to main branch
  • Many Sync issues, even if we all are working on different scripts, since creating a script through the GUI, alters the scripts.ps1 file.

For that reason, we’ve put the .universal folder in the .gitignore.

As a result, when for example we merge scriptA.ps1 to to our main branch (in the scripts folder), the script is only visible through Settings-Configurations, we have to manually add it to the ./universal/Scripts.ps1 file, to make it visible in PSU itself.
Same issue when my colleague, even in the same branch, wants to work on a script I created before, he first has to put it in his own settings.ps1 file.
Since we’re not creating that many new scripts, we prefered this way instead of dealing with all of the merge conflicts manually, at this moment this way of working is still doable.
But maybe there is a better way to tackle the issues here?

Earlier today I was also looking at the API/Endpoint functionality. Seems like this works differently as the scripts, since the endpoints themselves are stored within the /.universal/Endpoints.PS1 (or in a subfolder of the .universal directory when working with the -Path param)
So with our setup we cannot “play” with Endpoints, and later on push them to git (and merge them in main) - we would need to manually paste/copy them into the /.universal/ subfolder (maybe it’s possible to not ignore a subfolder in git, but that’s just an example of us struggling a bit)

When working with multiple branches (on my workstation), when changing a branch I noticed some issues as well.
Maybe if I would wait long enough, it would be okay, but I always restart my local PSU service now.

We’ve already decieded to use this platform as our central automation and scripting platform, but we aren’t sure which is the best way to work with it yet.
We want a good development environment for ourselves, and try not to test in our production environment (or at least as possible)

But since i’ve already seen so many success stories, I’m sure there might be a better way of working with PSU/Git integration than we do now.

Any feedback is appreciated.
Thanks in advance!

Stijn