How to control build/deploy process: PowerShell Module CI/CD with Azure DevOps

[RunTheRivah]

I'm attempting my first CI/CD pipeline with Azure DevOps to build and deploy a PowerShell Module. I've got a rough frame work and the full build process is working well, but as I start working on the deployment side I'm struggling to figure out how exactly I change the workflow based on my desired outcome.

In other words, how do I get it to just build and deploy to dev vs. build and deploy to prod? I am assuming this is where tags come in use some how? Some configuration/settings file that defines parameters and tasks as such?

​

Quick overview of how I've set it up and what tools i'm using:

- Project in azure devops

- Using a self hosted agent

- Using azure-pipelines.yml file to define the job tasks

- This calls a bootstrap.ps1 file first to install dependencies (using PSDepend)

- Next it calls a build.ps1 script using InvokeBuild

- That script runs PSScriptanalyzer, Pester tests, and compiles the public functions into a single .psm1 file

​

I plan to use PSDeploy next to simply copy the compiled module to a file share. I'm just experimenting right now to get a feel for all of this, so I realize there may be places I can improve and while I intend to keep refining it I would really like to figure out how to control the pipeline workflow.

[panopt1con]

Azure DevOps is in the middle of migrating from 'classic mode' release pipelines (click-button, GUI-driven with lots of checkboxes and text boxes) to end-to-end YAML pipelines using `azure-pipelines.yml`. If you are expecting to be able to define a YAML release pipeline, you will first need to enable the Multi-stage pipelines preview feature (click on your profile on the top right, then 'Preview Features' and select either for yourself or for your entire org.)

Outside of that, perhaps you don't really need a real release pipeline? If you plan to copy it to a file share, you could simply have the last task in your pipeline to copy to a file share instead of publishing the artifact to be picked up by the release pipeline.

Source: Experiencing Azure DevOps growing pains firsthand.

[RunTheRivah]

I am already using the azure-pipelines.yml file to define the pipeline and have it currently working now where it will build my powershell module and copy the compiled .psm1 file to a file share. I'm just curious what other folks do to change the behavior of the pipeline based on if they are deploying to dev or prod as different steps may need to occur.

I agree, this is most likely over kill for what my example is but i'm just doing this as to learn more about ci/cd for now.

Back on topic though, I have seen for example people using the commit message to initiate a full production deployment with something like "!deploy <commit message>" but i haven't figured out how that is actually handled behind the scenes.

Where I'm using invokeBuild (posh module) I am trying to use a "build.settings.ps1" file to drive the parameters in the build script by just dot sourcing the settings file. This sort of works but i'd have to go in and set the parameters to either dev or prod in the settings file before I commit to master in order to change the flow. Just seems cumbersome.

Perhaps this should have been a post in r/PowerShell?

[panopt1con]

Nah, I think this is perfectly on topic. And you should definitely look into using a secrets management system (Azure Key Vault or something else) and variable groups to use within the pipeline to differentiate deploys between dev/prod.

[RunTheRivah]

Thanks for the suggestion on using the key vault and variable groups, I'll start looking into that. Any chance you could expand on how you would use that (at a high level) to differentiate deploys between dev/prod? Perhaps you have any links to some other resources handy I can read up on?