Development Flow

PowerShell Universal
1 
Product: PowerShell Universal
Version: 4.4.1

We have two staging PSU servers behind a load balancer. They connect to an SQL DB and are set up for two-way sync with the staging branch in Git.

We have two production PSU servers behind a load balancer. They connect to an SQL DB and have a one-way sync set up to the main branch in git.

When the code is ready to move from staging to production, we merge it from the staging branch to the main branch.

We currently develop on the staging servers, but we want to start developing locally.

The idea is to do feature branches off the staging branch and use them locally. Then, merge those branches into the staging branch for testing before merging them into the main branch.

My question is, does that make sense? Is there a better way? How does everyone else handle this?

1 Like
2

This is exactly how I would envision the development flow would take place for larger teams. Typically, the issue is that local development is hard due to resource limitations like API keys or permissions.

What you’re describing is how I would see most developers working with git flow setting things up. For some teams, this type of development may be overkill but for larger teams, it’s how I would go.

It also depends a bit on your tooling whether this is the right way to go. PSU is not a feature rich git client so managing PRs, merge conflicts etc, would be better done in a different editor.

2 Likes
3

as someone whos ever used Git for tracking changes, how would you envision the flow to be for a smaller team of 1-2?

4

Do the prod/stage servers share the same schedule file? How do you handle that?

5

I added a section on git branching on the docs to address this. Let me know if you have more questions after checking that out.

2 Likes
6

I’m not OP, but I use a variable named Environment in my variables.ps1. It uses the name of the server hosting PSU to determine the environment. Then I conditionally set variables like script parameter values based on the value of $Environment:

#region PSUHeader
switch -WildCard ( $ENV:COMPUTERNAME ) {
    "*-t-*" { $Environment = "test" }
    "*-p-*" { $Environment = "prod" }
    Default { $Environment = "dev" }
}

New-PSUVariable -Name "Environment" -Value $Environment -Description "PSU environment"
#endregion

#region Environment-specific variables
if ($Environment -eq 'prod') {
    New-PSUVariable -Name "Domain" -Value "example.com"
} else {
    New-PSUVariable -Name "Domain" -Value "testexample.com"
}
#endregion

Then, in schedules, a schedule using the conditional variables will look like this:

$schedGetDomain = @{
    Script = 'scripts\Get-Domain.ps1'
    Cron   = '0 * * * *'
    Name   = $Domain
}
New-PSUSchedule @schedGetDomain

Edit to include a caveat: When you put variables in PSUHeader like that, they will get duplicated every time git syncs with new changes. You could probably add Remove-PSUVariable before New-PSUVariable to counter that, but I haven’t tried it.

Also: shoutout to mikedhanson who I think shared this trick with me… If it wasn’t Mike, shoutout to him anyway :sweat_smile:

2 Likes
7

I’m reading the “Single Users and Smalls Teams with a Staging Branch” section. Say I am using the dev/prod PSU servers with dev/main branches as described. Two way sync with dev, and 1 way sync with prod/main. When I PR dev branch to main, wouldn’t .universal\schedules.ps1 (and maybe other config files that have changed) get included along with my other changes? Maybe I need a .gitignore to prevent this?

8

Yes, if you don’t want to manage it with variables like I suggested, you would have to use some other method to merge the appropriate configurations into their respective branches.

Ideally, you would keep your config and code separate, but in PSU a lot of the config is code. If you want to separate the data from the code while still testing the code in the .universal/ folder, you’ll probably be entering the territory of CI/CD. That’s typically more complex than “Single Users and Small Teams” are used to.