I can share how we are doing almost exactly the same thing here in our situation too. I posted this question a while ago for the same type of situation where we have a Prod and dev environment on two branches and a different SAML connector in Okta for each environment: Prod/Dev Variable or logic
I dug around a bit more and have adjusted the logic we are using a bit so that it now looks like the below
Notes for it:
- In
variables.ps1
am using the#region PSUFooter
region so if anyone edits the vars on the UI it doesnt overwrite this part ofvariables.ps1
.
** The Prod instance is a one-way sync from themain
branch so the prod changes only come from Pull Request merges - In that region I wrote some logic to determine the environment and set it to a variable
- If I use
$PSUisProduction
inside variables.ps1 then it will return the value before this script ran - this tripped me up a boit while trying to set this up - We use that variable in scripts, apps, etc to then target dev or prod instances of apps we connect to - eg a different OU path in AD for test accounts, a different instance of ServiceNow for dev
variables.ps1
isnt the first script in the startup sequence, but its before most, and earlier ones likeinitialize.ps1
dont have access to the variables yet- Am using the
$Repository
path variable currently as its one of the few that exists at this point in the process, but could also use the git branch name, environment variables, the computername, or a value from a file that is outside the repository or in the.gitignore
- eg an “appsettings.json” equivalent that stores the data for the decision -
Im still debating if Repository is the “best” item to use for the logic as we work on some CICD processes around this, but it does mean we don’t have to exclude any core things from the Git repo.
Code is in the expander below
Variables and Authentication.ps1 files for those interested
variables.ps1
#... Bunch of variables above here
New-PSUVariable -Name "PSUisProduction" -Value $false -Type "System.Boolean" -Description "Is this a production environment?"
#region PSUFooter
Write-PSULog -Level Information -Message "Variables loaded - Setting Dynamic Values"
#Be careful in the use of $PSUisProduction directly after this point as it is evaluated before this script loads
Write-PSULog -Level Information -Message "PSUisProduction: Repo path: $($Repository)"
$isProdVariable = Get-PSUVariable -Name "PSUisProduction"
if($Repository -eq "D:\PSUniversal-Prod\Repository")
{
Write-PSULog -Level Information -Message "PSUisProduction: Repo name matched Production"
Set-PSUVariable -Variable $isProdVariable -InputObject $true -Integrated
}
else {
Set-PSUVariable -Variable $isProdVariable -InputObject $false -Integrated
}
# Spit out in the logs what it is
$isProdVariable = Get-PSUVariable -Name "PSUisProduction" -ValueOnly
Write-PSULog -Level Information -Message "PSUisProduction: Result=$($isProdVariable)"
#endregion
authentication.ps1
#Decide prod or not based on variable set at load
Write-PSULog -Level "Information" -Message "isProduction:$($PSUisProduction), isDevelopment:$(-not $PSUisProduction), Path: $($RepositoryPath)"
#set the SAML Setup depending on the environment - prod settings by default in case we have an error lower down - we can always fix dev
$samlOptions = @{
Type = "Saml2"
#... Secrets be Here
}
if (-not $PSUisProduction)
{
$samlOptions = @{
Type = "Saml2"
#... Secrets be here
}
}
# Set the Saml2 authentication connector
Set-PSUAuthenticationMethod @samloptions
#... Other auth below here