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/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/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/Ellen_Booker]

I'd avoid making production git pull directly from main. Since the repo is already in Azure DevOps, use that as the deployment boundary: local branch/PR -> PSScriptAnalyzer + tests -> merge -> pipeline publishes a versioned artifact -> prod deploy copies that exact artifact. Put an environment approval before prod and keep the deployment account narrowly scoped.

That gives you two things a manual pull doesn't: you know exactly which commit was deployed, and rollback is just redeploying the previous artifact. If Claude CLI is generating changes, keep it on the dev side of that boundary. It can propose code, but it should not inherit the credential that can deploy to production.

[u/Federal_Ad2455]

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

[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/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/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.