Powershell is what I would describe as a ‘stackoverflow language’. Its the kind of language that, as long as you’ve got some previous experience developing on Windows, you can just get started with by reading a few stackoverflow posts and copying and pasting a few code snippets here and there.
Very few developers out there take their Powershell skills and knowledge seriously and simply use it as a means to an end. This often results in messy, sprawling, untestable and unextensible collections of scripts which end up impeding rather than enabling development.
I have seen this in many teams I’ve worked in and I’ve been that Powershell stackoverflow developer. I experienced first hand the impeding nature this had on the development and release cycle but thankfully a while ago I started taking Powershell development much more seriously and started using lots of new and emerging technologies and frameworks to treat Powershell as a first class language. Here are my top tips of things you should be doing to if you want to start taking Powershell development seriously
Use a Decent Code Editor – Don’t use ISE
I use Posh Tools for Visual Studio and it’s heaven compared to the old days of ISE. I can organise all my script files into a project, I can debug scripts from within Visual Studio, I have all the power of the Visual Studio code editor and search functionality as well as direct integration with source control including in built in compareand merge functionality. I am amazed how I ever got anything done using ISE 😉
The extensibility of Visual Studio also guarantees that new features are always being developed to improve the entire experience. I hope one day we will have support in Visual Studio for Powershell that’s on a par with C# development.
There are other options as well, for example Visual Studio Code.
Put your Code into Modules
I can’t push this point enough. We all understand the benefits of putting our application code into libraries and defining a clear public API for our functionality.
Instead of the usual common sprawling pile of Powershell scripts full of inter dependencies your scripts should be put into Modules. Modules allow you to clearly define what functions and cmdlets are public whilst keeping any internal implementation hidden.
Powershell modules allow you to define a rich set of meta data on your code including, versioning and dependencies.
By using modules we are again promoting our Powershell code to the same level as our application code and treating it as a first class citizen in our development environment.
Unit Test your Powershell
We’ve been talking about unit testing our application for years now, in fact not unit testing application code is a sure sign that a project is failing. In spite of this I often come across untested Powershell code. This is even more worrying given all the talk of ‘infrastructure as code’. Your infrastructure creation and management code should be considered part of the application and as such should benefit from the same level of automated testing as the rest of your application.
There are a few different unit test frameworks for Powershell out there nowadays. The most popular is Pester, it’s open source, proven and comes with a great mocking framework.
I’m not going to go through all the benefits of unit testing, they should be obvious. By unit testing our Powershell we promote it to the same level as our application code and make the goal of infrastructure as code more of a reality.
PSScriptAnalyzer will catch any silly typos you might have made as well as ensure you stick to coding standards and best practices.
PSScriptAnalyzer will save you heaps of time during the development phase by catching silly errors before you start any testing and ensure consistency across your Powershell codebase.
Use PowerShell Help
To make your modules as useful as possible and your functionality discover able to your users you should be documenting your functionality using these systems.
Publish your Modules to Nuget
The new Package Management Module for Powershell allows us to publish and install our Powershell modules to a nuget repository and this is what powers the PowerShell gallery, the new public repository for Powershell code. Powershell package management is included in Powershell 5 and available as a separate module for Powershell 3 and 4.
The advantages of being able to easily share and distribute you code as a package should be obvious. Package management in considered standard for most fraweworks languages nowadays.
Clients of your modules can easily install your modules and maintain multiple copies of it side by side. Again, your Powershell code is treated in the same way .NET and other languages have always been.
Read a Book
Don’t just rely on stackoverflow and code snippets you find on the web. Read a book and learn the fundamental concepts and structure of the Powershell language. There are many hidden gems in the Powershell language that many developers remain unaware of because they’ve never been exposed to them.