This topic contains 4 replies, has 3 voices, and was last updated by
December 12, 2017 at 3:41 pm #88874ParticipantPoints: 5Rank: Member
I have a load of scripts/functions/modules etc. that i have handed over to the support teams to use in Production. The scripts range from password resets to building entire IaaS in Azure.
Currently i have a folder with the scripts in which are launched from a .bat file. When the support staff run the .bat file the scripts executes and do what it's meant to do.
How do other people hand over their scripts, whats the best way for other user to run these?
Any ideas, suggestions would be great
December 12, 2017 at 3:43 pm #88877KeymasterPoints: 1,704Rank: Community Hero
I don't write scripts; I write functions. I bundle them into task-related modules, and host them on a private NuGet repo. Anyone can then use Find-Module and Install-Module to get them, and then just run commands as if they were "real" PowerShell commands. I provide help files and everything. That way, the tools I write follow the exact same patterns as everything native to the shell, so people only have to learn one way to do things. I even wrote a book about it (grin).
December 12, 2017 at 3:50 pm #88880ParticipantPoints: 5Rank: Member
Thanks for the rapid reply Don 🙂
I like the idea of a private repo and letting the support staff download the module and execute the function. But the problem with that is the support staff would need to be educated on how to use PowerShell terminal/ISE or VSCode which i suppose is the correct path for people, but not that easy.
So, would launching the PowerShell scripts via .bat files and having kinda menu items appear be the 2nd best way?
P.S What's the book?
December 12, 2017 at 3:53 pm #88889KeymasterPoints: 1,704Rank: Community Hero
I tend to not compromise just because someone is too scared to learn to open a text editor ;).
No, tools in modules is still the right way. Those are TOOLS. You could easily build a CONTROLLER script, which is more of a standard script with a menu or whatever. THAT could certainly check for the local existence of the modules, install them (even from a file share) as needed, etc.
And if teaching someone just to open a PowerShell console window (you'd never have them use the ISE or VS Code for this) and run a command is too hard, you should have a serious discussion with your HR department. Ensure that job descriptions are modified to include "will be required to perform minimal actions in a command-line console, including running defined commands." And then start educating everyone to come up to speed, and imply that if they can't do the job there are plenty of people in the world who can.
December 12, 2017 at 7:31 pm #88930ParticipantPoints: 38Rank: Member
I've been down this trail myself, simple scripts are one thing to just tell people to learn how to do basic commands. But, unfortunately, you will always wind up with the standard old school windows admin mentality, IE if i can't click a button, and run a wizard, it is impossible to achieve..
When you get into more complex tasks, i've found it so much easier to just build a gui executeable.
The Month of Lunches books from Don, as well as the powershell tool making month of lunches have been vital in getting myself to a point where i'm comfortable building entire tools for other teams.
I've also seen once people start having custom GUI's created to automate tasks for them, it actually generates positive interest in powershell and how the back-end all works. IE you took a task that was 15+ clicks in random gui windows interfaces and distill it down to a single action suddenly the usefulness of powershell becomes interesting.
The topic ‘Promote to Production.’ is closed to new replies.