As you already know if you have read this or this, I’m a big fan of PSScriptAnalyzer to maintain a certain coding standard. This is especially powerful inside a release pipeline because this allows us to enforce that coding standard.
Nowadays, many IT shops look a lot like the first few pages of The Phoenix Project : lack of automation and communication which leads to manual and unpredictable deployments, which in turn, leads to firefighting.
Coding, especially in PowerShell, is not about remembering the exact syntax of how to do something, it is more about knowing how to try things out and to get the information we need to do whatever we need to accomplish.
I read Jeff Hicks’s article about “Dancing on the table with PowerShell”. The content is really quite fascinating (go read it !), but I got hung up on something.
Recently, I had to roll out an upgrade of our software for a customer. The upgrade failed for about 80 client machines (out of around 400). There was a lot of head-scratching and quite a few :
Unit testing PowerShell code is slowly but surely becoming mainstream. Pester, the awesome PowerShell testing framework is playing a big part in that trend.
As you probably know, PSScriptAnalyzer is a static code analysis tool, which checks PowerShell code against rules representing best practices and style guidelines. This is a fantastic tool to set coding style and quality standards, and if we want to, we can easily enforce these standards within a ...
When writing a DSC configuration, separating the environmental data from the configuration logic is a best practice : it allows to reuse the same logic for different environments, for example the Dev, QA and Prod environments.
Many of us who are writing PowerShell code are using Appveyor (especially for personal projects). And most of us use this to run Pester tests. Automated testing is great, it allows to set a certain standard of code quality without slowing down code delivery.
As you may already know, the only PowerShell certification program is being abandoned. Some people in the PowerShell community are trying to justify this by saying “There is no need for PowerShell cert” or “it’s too difficult to test PowerShell knowledge”.