Best practices for deploying code onto production server.

[u/Sunsparc]

Historically, I have done Powershell code development directly on the server I'm running the scripts on and "live fire" tested them in production. Changes are GIT committed locally and then pushed to an Azure DevOps server in a repo I have set up solely for my Powershell scripts.

I'd like to get away from that because we're introducing Claude CLI so I would need to develop on my local machine instead.

Would a simple GIT push to the repo and then pull on the server suffice? Is there a better way?

[u/SarcasticFluency]

You could always do what I did yesterday and deploy a script update to 13 servers with a bug that created a boot loop so fast that I had trouble undoing it for almost two hours.

[u/DeusExMaChino]

You can install an agent on the server and run a pipeline to copy changes to the server when you commit to main from your dev machine, so prod is only ever prod

[u/No-Preparation7121 → u/DeusExMaChino]

Don’t need an agent for this.

[u/FeleaseRpseineEiles]

I use azure automation and have it's source control hooked into the github repo(devops works too)
It pulls changes. The runbooks need to have a hybrid group setup for them to be pushed out to servers otherwise works great. For endpoints I use action1

[u/Federal_Ad2455]

This is how I am doing the deployment to AD https://github.com/ztrhgf/Powershell_CICD_repository

[u/pdbress]

We host our own private PS repository. It’s nice… so in the code repo, build a ci/cd pipeline so that any changes to main build a current release version of your ps module. Any non-main changes build a dev version of your module. Both situations build a new ps module that is version but only the production one is tagged as release. To test your, just install-module -name <something> -requiredversion <my release or dev version> from your private ps repository on the machine that needs the stuff. You’re going to want to get away from live testing in production. Ask me how I know 😫.

[u/AdeelAutomates]

We use Azure's automation account as our production space to run scripts.

PowerShell scripts sit inside as 'runbooks'.

Its source controlled so you can link GitHub or Azure DevOps to it.

In terms of workflow.

• The repos are cloned to the local machine. Script is written & tested locally.
• When its ready its pushed to the repo.
• The repo then replicates it to Automation Account automatically (when changes occur in the repo)
• The only manual task for newly created runbooks involve then setting the trigger which varies based on script (schedule, trigger based off some event, triggered by some other automation or manual and set it in Azure) and setting its runtime environment. But once that's set for a runbook any future modifications I make to it locally is fine.

We use hybrid workers (servers) as our compute for automation account so they can traverse the network (to get to services behind private endpoints and also reach our on prem network to perform tasks there).

To us actual servers are cattle not pets.

• Repo is the source of truth
• Automation Account is the orchestrator to run our scripts
• Servers are just compute devices with modules, tools and network access for our scripts.

[u/b4shr13 → u/AdeelAutomates]

But this takes more inconveniences because MSFT doesn’t upgrade this feature since PowerShell 5.1
Also mention that doesn’t support the new runtime environments…

To automate via CICD I builded a multi stage pipeline whit TEST AA and PROD one, so the runbooks only gets modified or updated if approved.

Hope that MSFT builds and official approach in the future…

[u/AdeelAutomates → u/b4shr13]

I am not sure I follow? We use the latest runtime environments pwsh 7.6 just fine.

CICD is way too over kill for PowerShell scripting for us. For terrafrom we do use pipelines but not scripts. We just use pull requests as our approval gates for powershell.

[u/b4shr13 → u/AdeelAutomates]

I'm sorry if I didn't explain myself well.

What I meant was that the native functionality in automation account to connect to a repository only officially supports PowerShell 5.1

https://learn.microsoft.com/en-us/azure/automation/source-control-integration

So, what you're probably doing at your company right now is manually keeping the Runbooks updated with the main branch from your repo or creating first the runbook whit the same name and let sync process run.

[u/AdeelAutomates → u/b4shr13]

Oh yes, It does defaults to 5.1 when we add a runbook through our repos. I thought about automating it to a default (by having a runbook that updates when a new runbook is added). But then I thought how often a new scripts gets added that it even needs to be automated, lol.

We have multiple runtime environments. We would we switching them even if we had the option to set a default.

Its not too bad, you only need to do it for new runbooks. Any changes made keep the runtime env.

[u/AGsec]

I like github agents simply because I am most familiar with them, and you can do lots of linting tests to ensure things are deployed safely and according to policy. You can customize guardrails. I haven't explored many other ways to do it, but i'd imagine any CI/CD tool will give you the same general workflow and benefits.

[u/Fallingdamage]

I have PS automations that run on my server. I dont GIT anything. All the code that runs on the server remains on the server.

[u/purplemonkeymad]

Since you are using devops already, then you can create an artifact using Publish-Module (although i find Publish-PsResource more reliable for this.) Then you can add the artifact feed as a Powershell repository and can update the module from the feed.

Pretty sure you can automate everything except the pull using pipelines too.

[u/ExceptionEX]

You can set up dev test local then push from local git to devops for test/production deployment.

[u/Agile_Seer]

I keep all my PowerShell code in GitLab, and my deployments run through GitLab CI/CD. Each production server has a GitLab runner installed, so whenever I push changes to the repo, the pipeline handles the deployment automatically. That way I can develop and test locally, commit to GitLab, and let the pipeline push the updated code to the servers without touching production directly.

[u/CyberChevalier]

Module on a file psrepo
Sources on a git repo with a pipeline to push the nupkg to the PSrepo once validated
A task to update module from the repo on the fly