How do you Manage PowerShell

This topic contains 8 replies, has 3 voices, and was last updated by  Josh Miller 3 years, 5 months ago.

  • Author
    Posts
  • #14555

    Josh Miller
    Member

    Thinking about a general "Ways to Manage" your scripts as a topic for the DFW PowerShell User Group.
    We have in the past discussed many ways to package and run scripts from Batch files, shortcuts and EXE.

    What I am curious about is how people manage running them.

    1) How do you Run the script in production?
    – Scheduled Job
    – Manually running script from shortcut or console
    – From a web interface
    – PowerGUI UI
    – Others

    2) How do you store your scripts?
    – Everything is local
    – File Share
    – local files pulled from a repository
    – Others

    3) How do you vet scripts for production use?
    If there is a production Script location how are you vetting scripts before they move there:
    – Pester
    – Parse for Script Errors
    – Change Management / Review and Authorization
    – Others

    4) Do you classify your scripts (Risk areas)?
    – Production Critical(if this breaks someone is going to be bothered)
    – non Critical Reporting (production, but failing can be identified and corrected)
    – Workflow helpers/shortcut process (Okay if it fails)
    – Fun/Toybox
    – Others

    5) Do you track business owners and maintainers to keep up with scope and change risk?

    Thanks,
    Josh

  • #14556

    Dave Wyatt
    Moderator

    1) How do you Run the script in production?
    Depends on the script. Some are scheduled tasks, others get pushed out via some of our management software, and scripts that I write for myself (to do data analysis / etc), I just run manually in the ISE or a console.

    2) How do you store your scripts?
    In our retail environment, we send a copy of the scripts to each server to be stored locally. The WAN links can be pretty slow at busy periods, so that's mainly a performance / reliability concern.

    3) How do you vet scripts for production use?
    Aside from my own testing before the scripts go anywhere, we have a pretty rigid QA / Beta / Pilot / Deployment process for change management. I don't think our QA team does any kind of formal unit testing on scripts, but I do that before I send the script to them. I've just started playing with Pester and PSate. I like them both, but haven't used them much for production code in the office yet. (I used PSate to test Invoke-GenericMethod)

    4) Do you classify your scripts (Risk areas)?
    Not formally, though they obviously do fall into those categories in some way or another. (Mostly either Production Critical or Non Critical Reporting, with the scripts I write for my own use falling under something like "Who cares? I can always rewrite it.")

    5) Do you track business owners and maintainers to keep up with scope and change risk?
    Not really. Because we don't load modules from a central location, we don't need to keep track of who would be impacted if we needed to go back and change functionality in an existing module. Each script will be packaged with the version of the module it requires.

    • #14567

      Josh Miller
      Member

      [quote=14556]1)
      2) How do you store your scripts?
      In our retail environment, we send a copy of the scripts to each server to be stored locally. The WAN links can be pretty slow at busy periods, so that's mainly a performance / reliability concern.
      [/quote]

      I do a combination of a nightly sync using Robocopy /R:0 to overwrite changes on remote boxes with a list of remote servers to "Push to" and a subscriber Sync that works the same way that calls the batch on a mapped drive and syncs locally, so I can update a workstation or test server with the scripts. I also keep command line tools and sysinternals Apps.

      Dave, What type of Management Software SCCM? I know it sounds stone age, but I don't have it.

      Thanks for the notes.

  • #14568

    Dave Wyatt
    Moderator

    I can't really get too detailed about our environment, unfortunately, without risking trouble from IT Security policies. I'm pretty sure it's safe for me to say "We use some PowerShell", "we have WAN links", "we have management software", and "there's a change control process." 😉

  • #14575

    Josh Miller
    Member

    I can live with that. I appreciate the notes you gave.

    Any idea on a focused enough search terminology to look for what other people are doing in these areas? Best Practices of $ScriptDeployment....

    Everything I search for on best practices goes back to coding practices, Searching for deployment pulls up using Powershell to manage a deployment of some type.
    I am not finding anything on deployment patterns of written scripts.

    Thanks again,
    Josh

  • #14576

    Dave Wyatt
    Moderator

    Gotcha. There's really nothing different about deploying scripts from any other type of software (whether purchased or developed in-house), so you can probably get better results by searching for software deployment instead of script deployment. For instance, you might go with a software development workflow, using something like Git with branches / pull requests / code reviews / merges / etc, ultimately finished up with a build/deployment script that pushes the production branch out to your systems in some way. That deployment script may involve updating a source package that agents on the target systems will pull from later, or a push-based model; that's a decision for you to make. Pull models tend to be more hands-off, forgiving of temporary network outages and such.

  • #14582

    Josh Miller
    Member

    That is the direction I was going with it. Trying to get a better idea what other people are doing, and less what they should be doing. I wanted material issues to try and build a user group discussion on.

    I was panicking on: Deploying a web application is one thing, deploying scheduled maintenance scripts another, letting everyone in IT run consistent employee onboarding process is another... and that was all overkill.

    I guess I should start it with more of what my scenario are and less on what they may be seeing. If they ask about something I didn't consider, I can always think on it, and circle back around the next month.

    Thanks for the sanity check, it is a user group not a book to write. 🙂

  • #14637

    Bob McCoy
    Participant

    With all due respect, there is not a question above where the appropriate answer wouldn't be, "It depends." And it depends on a number of things:

    • How risk adverse is your organization?
    • How many systems are you trying to "manage"?
    • What software/file distributions do you already employ?
    • What administrative controls (versus technical controls) do you have in place?
    • What is your current release mechanism/environment from pushing code from development to test/QA to production?

    Depending on the risk posture, your organization may put scripts in the same class as any other software pushed into a production environment.

  • #14670

    Josh Miller
    Member

    Bob,

    I was looking for samples to include with my own practices for a User Group presentation. I was looking for feedback on what other things may apply, not that someone pick item 1, 2, or 3. This does enter into the world of "Everything"; Which is why my last post backed down and conceded that I should just go with what I have. That will easily feed an hour discussion on its own.

    I think there is a fair number of organizations that have operations groups that have no tie to an internal development team, and are trying to move away from "Click-ity administration". That was more of who I was seeing as the target audience.

    – Josh

You must be logged in to reply to this topic.