The use of proper tooling is the first and most important step on your journey to enterprise level scripting. Proper tooling can save you time in development, help you design better solutions and most importantly show the value of your hard work to anyone who may be interested. I will break this down into two sections, Development Tooling and Project Tracking tooling.
First and foremost get used to change. The tool sets change regularly, get used to it. For scripting in a Windows environment I could go on and on about the different development solutions out there like PowerShell ISE, VS Code, NotePad++, Primal Script, full blown Visual Studio and many more. The important take away here is to use one of them! Do NOT use notepad.exe for your development. Why would you subject yourself to such pain when so many other great solutions exist?! If you are going to be scripting in multiple languages (VbScript, SQL, PowerShell, etc.) try to use a single editor for all of them. Not a different editor for each language. This of course isn’t always possible, but definitely keep it in mind. Having a single development environment can really streamline your development process if by nothing else preventing you from having to constantly shift around from one app to another. I am partial to VS Code. It is, in my least humble opinion, the best development tool that exists today for the type of automation work I am doing.
ProTip - Learn the keyboard shortcuts for your code editor. VS Code Cheatsheet
PowerShell and VS Code
I am really quite partial to VS Code. It is open source (free), updated regularly and integrates VERY nicely with a lot other tools like source control and many project mangement suits.. It is highly customizable, but out of the box it works great. No need to get deep into the weeds with all the customization options unless you want to. VS Code has way more feature rich integrated console and debugger compared to the ISE but there are times when the Integrated PowerShell session becomes unstable and needs to be restarted. For PowerShell development with VSCode get used to the “PowerShell: Restart Current Session” command. This will almost always fixes any weirdness that pops up with the intergrated terminal. The native PowerShell ISE does not have these instability problems but it also hasn’t had any updates in many years and probably never will ever again so it is safe to say it will not be getting any better. For you ConfigMgr administrators out there, think of the PowerShell ISE as legacy Packages and VSCode as the Application Model. One is nicer but more challenging the other is simpler, less feature rich but it does just tend to work.
Here is an outstanding over view of using the PowerShell extension in VS Code by the lead developer of the extension. Minute 37 is my favorite, remote debugging FTW!
.NET (Visual Studio or VS Code)
For enterprise automation using .NET I would say that VS Code offers the same functionality as full blown visual studio but is free instead of $10k/year. If you are doing UI or full .NET development you are still going to want to have full Visual Studio available as VS Code doesn’t fully support the full desktop .NET development only .NET core. If you are going to be creating any type of GUI you will likely benefit from a full install of Visual Studio instead of going with VS Code regardless of what flavor of .NET you are working with.
Project Management Tooling
In this section I am going to propose adding a fair amound of overhead or what would at first glance appear to be busywork. Wrong! These recommendations are essential to having your automation and scripting be accepted and widely adopted in your enterprise. Even if you are not going to be using any neat integration features or source control. Even if you a single coder working alone a good project management solution that fits your needs is essential. If nothing else it is good for time tracking and forecasting. Don Jones, genius extraordinaire, once said something that I have never forgotten. “If you don’t take your scripting seriously no one else will”. Proper task and time tracking is the first step to professional enterprise level scripting.
I recommend tracking your work with as much detail as you can afford. Before starting any automation endeavor break down the project into its basic parts and record those parts into a project tracking software. Take a chance to look at each basic part of your project and try to forecast the amount of time it will take you to complete the tasks. If you think any task will take more than 8 hours, break down the task even further into more manageable parts. Using manyh smaller tasks to make up a bigger story it is easier to see progress and be able to have multiple people work on a single script\automation process\story\whatever you want to call it.
A project management software I have become very fond of is VisualStudio.com. It is an easy to use agile\scrum project management software with nice visual and lots of available integrations with things I mentioned later, mainly source control. Trello is also amazing. I currently have to use JIRA and it works just fine. I am pretty sure simple excel could do a wonderful job at time tracking too if properly maintained, but don’t recreate the wheel. Try to use an existing tool before rolling your own.
Utilizing a project tracking solutions give full transparency to what is taking up your time and if done properly you can use the tooling to tell a really good story about how dedicated scripting / automation time is valuable and how much have definitive metrics to back up your assertions . Besides, it is good practice towards a “DevOps” mentality which is the future of the profession. The sooner you start adopting the methodology the more marketable you can be. This cannot be understated.
Project Breakdown Example -
Automation Project - Check the status of all CM application and package content
a. Create least privileged service account
b. Write tests for your code (or at jot down what you will be testing, this takes practice)
c. Query all Packages
d. Query all Applications
e. Query all Content on DPs for packages
f. Query all Content on DP for applications
g. Define “bad content”
h. Test for Bad content
i. Remediate bad content for packages
j. Remediate bad content for applications
k. Report on what was found
l. Finalize tests for script
m. Peer Review scripts
n. Peer Review Tests
o. QA with “customers”
p. UAT Deployment
q. UAT monitoring
r. CR for prod. deployment
s. Prod deployment
t. Production monitoring
u. Debriefing / lessons learned
Lots of the above tasks can likely be broken down even further.