Maintaining scripts and version control

So, here is a problem that has started affecting Admins working with PowerShell. It’s a problem that Developers have solved for years, and expert PowerShell automation/toolmakers have followed suit. For the newer scripter a problem you’re going to start to have is maintaining scripts over time – especially after months of changes.

Imagine maintaining a module or script, making a change or adding a new function – everything seems to work fine, then two months later someone says – “Hey that script doesn’t work anymore!”  Oh my god, what change did I make last March 3rd – I have no idea.

Version control is the ability to rollback or compare your current version with an older one so you can see and examine the changes that have been made over time. Developers can use products like Microsoft’s Team Foundation Server, but this is a complicated implementation if you don’t already have it. Many PowerShell experts also use DropBox or Git – also that have limited features and require some manual work.

There is a product that I use that I wanted to let everyone know about – and right now it’s free. It takes all the “thinking” out of the process and doesn’t require you to install infrastructure services, database, SharePoint and other tools.

I’m not trying to sell this product – it’s just the one I use – so if you already have something you like - don’t bother yelling at me. But I do want to open up a conversation about version control – what do you use? Do you need it? What are some ideas?

Here is a video of the one I use – check it out if you want – and please share your thoughts!!!



Knowledge is PowerShell,





About the Author

Jason Helmick

Jason is a 25-year IT veteran and full-time author for Pluralsight. He is an avid supporter of the PowerShell community as board member and CFO of PowerShell.Org. He is the author of Learn Windows IIS in a Month of Lunches and contributing author to PowerShell Deep Dives, along with a columnist for TechNet Magazine and many other industry publications. He is a frequent speaker at many conferences and can be contacted on Twitter: @theJasonHelmick


  1. If you don't need the comparison feature you can resort to a filesystem watcher which when triggered can copy the modified file to another folder.

    Here's a short explanation:
    Just put the copy and rename operation in the action script block of Register-FSWatcherEventHandler.

  2. I've used a number of systems over the years, my current favorite is git. It's free, open source, very fast, and works very well in disconnected mode.

  3. git is quickly becoming the defacto source control system for developers across all platforms. It takes a while to get up to speed but once you put in the effort you will not be disappointed. If you don't want to deal with the command line I would advise downloading from the github site. It is a gentle entry into setting up git on your pc, and makes it dead easy to push your local repo to github if you so chose.

    • There is a rolled up newspaper waiting to swat you in the nose. All kidding aside think of your team members and how your workflow will scale to include them. Though this works for you it will not work for your team, and eventually make your script folder look like a graveyard of scripts. IT Pros need to learn how to act more like developers (did I just say that?) and put processes in place to more easily distribute there code, and not have it linger on some obscure folder on their hard drive, or some remote file server.

      • I'll consider my nose well and truly swotted! 🙂

        To be honest, I'm not convinced that I personally need full-blown version control. The scripts are on a shared server, they're dated, commented (usually!) and I can run diff between any two versions.

        I'm a one-man band on the powershell side, but when I've worked in teams in a bash environment, dated copies have typically been enough. At least I've never come across a scenario where I've felt version control was the answer.

        I can see huge value if you've got geographically-scattered teams or teams doing different shifts, but otherwise I can't, really.

        I should say I'm speaking from ignorance - I haven't used a real version control system properly since I was in development - a very long time ago. Am I missing something?

        Perhaps it's a question of an old dog, and new tricks 🙂

        • The great thing about git is it is just as well suited for a one man show as it is with a full distributed team. But, in the end if this works for you who am I to judge.

  4. I have been using version control for at least 20 years and it has saved me from several very bad situations over the years. Currently I am using Visual Source Safe, but I am looking to migrate to git. I like the look of the product from Sapien, but I would not consider evaluating a product that I did not know the price of up front. I do like the way it is architected.
    I would not consider doing any serious coding without a versioning tool of some sort. Besides the the recoverability options, being able to sit down with an auditor and give them the exact changes between any two versions of the code is a requirement (and I more often use it to figure out the changes myself).
    There is one problem that I have found versioning PowerShell scripts. We use keyword expansion to document what version of a file we are looking at and we even display some basic version information in the output that we generate with PowerShell. It is really nice to be able to determine the exact version of code that was executed to produce a given output. We also sign all of our PowerShell scripts and have an execution policy set to RemoteSigned. What I have found with PowerShell (which is not really a PowerShell issue as much as it is an issue with signed scripts in general) is that checking in a script changes the expanded keywords which then breaks the signature. So I work around this by always checking the file back out and then resigning it (I use Sapien PowerShell Studio mostly because it can be set to sign a file whenever it is saved).
    To give you an idea of what the keyword expansion looks like:
    $Workfile: Compress-Folder.ps1 $
    $Archive: /prod/common/Compress-Folder.ps1 $
    $Revision: 3 $
    $Modtime: 4/24/12 6:27a $
    $Author: mlewis $
    This shows up in the help for the object. The text after each keyword is filled in by SourceSafe (but almost all SCM tools have a similar capability).
    And we also display some debug information at the end of a script output:
    $Parms =
    HadError = $_hasError
    ScmLine1 = "`$Archive: /prod/project/billview/batch/Move-CisToAnchorBills.ps1 $"
    ScmLine2 = "`$Revision: 25 $"
    ScmLine3 = "`$Modtime: 5/16/13 12:23p $"
    Show-ReportFooter @Parms
    So the work-around works, but I would prefer to to have the final signed version checked in rather than having to leave it checked out and then signed. However, I am not willing to give up signed code, nor keyword expansion, so I will just live with it.