What is the best practice for deploying a script?

This topic contains 0 replies, has 1 voice, and was last updated by  Forums Archives 5 years, 7 months ago.

  • Author
    Posts
  • #5608

    by scottbass at 2013-02-27 21:35:39

    Summary]
    What is the best practice for deploying a generic, utility script? This script should be available to all Powershell users, but will will also feed other utility scripts. Convert to a function? Create a module in the global location? Put the script in the environment path? Something else?

    Details]
    I'm writing yet another "remove files older than X" script. There are numerous examples "out there" – browse http://gallery.technet.microsoft.com/si ... xt=Storage for examples.

    However, IMO the heart of the issue is deriving the collection of items to "do something to". I'd like to separate the derivation of that collection (the selection criteria) from the operation to be done. In my case, I need to 7-zip the files, then delete the original files.

    So, I've written List-Files.ps1, which I believe is useful in its own right, and I'd like that to be available to everyone. I'll then use this as the "engine" to write Archive-Files and Remove-Files. If I write Archive-Files and Remove-Files to support both pipeline and command line input, I'm thinking the final script could go something like:

    List-Files | Archive-Files | Remove-Files, where Remove-Files only executes if a zero return code is returned from Archive-Files. And removing files could be as simple as List-Files | rm

    However, what I don't know is the best approach to make List-Files available to all users? I'm thinking I should re-code it as a function (trivial), then put that in the "right location" so that it's available as a new "cmdlet". The same issue will apply to the Archive-File and Remove-File scripts.

    I've attached List-Files for the curious.

    Thanks for the advice,
    Scott

    by DonJ at 2013-02-28 06:37:10

    Build it as a script module, which would contain functions, put it in a central location (file server), and add that location to the PSModulePath environment variable of your PowerShell users (that can be done via GPO).

    So you'd put the module in \\Server\Files\Shared\PowerShell\Stuff\Modules\MyTools\MyTools.ps1

    Then add to the PSModulePath env variable \\Server\Files\Shared\PowerShell\Stuff\Modules

    And then the List-Files would be available. That said, "List" isn't an approved verb so you'll generate a warning when loading the module. It should probably be "Get." As a practice, put a prefix on the noun. If you work for IBM, Get-IBMFiles, for example.

    by AlexBrassington at 2013-02-28 09:35:00

    Dont forget to sign the module. 😉

    If you're deploying something that is going to be present in everyone's environment path you really should be signing it.

    See here: http://www.hanselman.com/blog/SigningPowerShellScripts.aspx

You must be logged in to reply to this topic.