Author Posts

March 9, 2018 at 12:04 pm

Does anyone have a good approach to versioning of PowerShell scripts and functions? It would simple if "VERSION" was a command-based help keyword, then the version number could be easily auto-updated via CI pipeline or build task.

Basically trying to introduce proper versioning of all functions in a solution, and also have the version easily retrievable for diagnostics/logging purposes.

Cheers,
Dave.

March 9, 2018 at 2:49 pm

That's what a manifest is for! Easily updated via code. Do it all the time.

March 9, 2018 at 3:00 pm

Hi Don. Sorry, should have been clear. I'm using a modular approach with private and public functions (each function is in its own .ps1 file). So the module itself has a manifest with versioning, but the goal is to have more granular versioning down to the function level.

Maybe doing it at manifest level of the module may work. Just be nice to do a Get-Command on a module and not have all the functions listed as version 1.0.

March 9, 2018 at 3:07 pm

PowerShell's ethos is that a module is the most granular unit of versioning and distribution. If you're wanting to do anything more granular, then you're more or less on your own, and working outside the shell's native stuff. The reason it's at the module level is because that's what gets distributed to people; internally, for more granularity, Microsoft itself relies on their version control system if they need to retrieve previous versions, and refers to them by those builds. But an individual function isn't seen as a standalone unit of work.

The most I can think of is a comment-based help field that you repurpose, or a private hashtable within each .ps1 that you put your own metadata into.

Personally, I've not taken this approach of a function-per-.ps1; a module is usually one .ps1 for me, and I test the whole thing. My tests are tagged, so if I know I only need to test a certain function, then I just have Pester test only the tests with that function's tag.

March 9, 2018 at 3:44 pm

A couple of thoughts. You could use git as a source control but if you want proper source control you would have to use the likes of visual sourcesafe (others are available)

But the following links you may find useful

https://blogs.technet.microsoft.com/dsheehan/2017/07/27/maintaining-version-control-over-distributed-powershell-scripts/

https://blogs.technet.microsoft.com/heyscriptingguy/2012/12/28/protect-your-powershell-scripts-with-version-control/

March 9, 2018 at 4:00 pm

All the code is already in git (well VSTS). One of the main goals is when the code is executing the detailed logs include the version of the scripts and functions. And ultimately those versions will track back to to a check-in and successful unit testing.

But maybe updating the module version is the way to go, even when the check-in may be a single change in a single function.