Script/Function Versioning

This topic contains 5 replies, has 3 voices, and was last updated by  Dave Brannan 2 months, 2 weeks ago.

  • Author
    Posts
  • #95532

    Dave Brannan
    Participant

    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.

  • #95552

    Don Jones
    Keymaster

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

    • #95561

      Dave Brannan
      Participant

      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.

  • #95568

    Don Jones
    Keymaster

    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.

  • #95571

    Simon B
    Participant

    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

    • #95574

      Dave Brannan
      Participant

      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.

You must be logged in to reply to this topic.