I have previously written about working with the ServiceNow API, and I’ve continued to use it since my last post on the topic. One of the things that I find myself doing a lot is using PowerShell to add a work note to an incident. Luckily, ServiceNow has an API that you can use to interact with it and do this (among many other things).
Registration for the PowerShell + DevOps Global Summit just opened today. This thing sells out every year so now is the time to start getting approval to attend if you need it, and buy a ticket.
Check out the event brochure for info about the conference. You can use it as leverage to convince whoever needs convincing that you should go. The PowerShell + DevOps Global Summit speaker line up and session schedule is also up right now, and as you’ll see, it’s absolutely stacked. This is also a great chance to meet people who work at Microsoft on the PowerShell (and other) teams, as well as a bunch of MVPs at the top of this field. Make no mistake, this is a crazy good networking opportunity.
There are limited hotel discount codes available, and plane tickets will probably only rise in price as you wait, so get on it if you’re going to come!
Some of the sessions I’m most excited for are Kirk Munro’s Become a PowerShell Debugging Ninja, Warren Frame’s Connecting the Dots with PowerShell, Eli Hess’ PowerShell IoT, Ryan Coates Build Release Pipeline Model For Mere Mortals, Will Anderson’s Automate Problem Solving with PowerShell, Azure Automation and OMS, and of course the session that I’m presenting, A Crash Course in Writing Your Own PSScriptAnalyzer Rules.
It’s going to be really hard to go to a “bad” session, though. With this line up, it’s going to be impossible not to learn something valuable no matter which sessions you attend.
Hope to see you there!
The Pester people don’t really recommend this, but, I find it can be really helpful sometimes. What I’m talking about is dynamically creating assertions inside of a Pester test using PowerShell. While I think you should strive to follow best practices, sometimes what’s best for you isn’t always a best practice, and as long as you know what you’re doing, I think you can get away with bending the rules sometimes. Don’t tell anyone I said that.
I try my best to make new technical posts on this blog every Wednesday morning. They vary in length, skill level, and sometimes even usefulness. Today I wanted to share that my first Pluralsight course was published last week: Getting Started with Azure Automation.
Pluralsight is a paid service but trials are available, and it’s a benefit of having an MSDN subscription. They’ve got thousands of hours of good stuff for people working in all areas of technology, including my new course.
My Getting Started with Azure Automation course will take you from zero knowledge to functionally useful in just over an hour. Please check it out and don’t hesitate to contact me with any questions or feedback.
As a Pluralsight author, I am compensated for creating courses so this is technically a sponsored post. I do, however, truly believe in their service overall, and think many people who read my blog may benefit from watching my course.
I’ve got a number of custom PSScriptAnalyzer rules that I sometimes run. A little while ago I uploaded them to GitHub to share with others. Today I’m going to walk you through the AvoidImproperlyCapitalizedFunctionNames rule I wrote.
So, you’ve got a certificate stored in Azure Key Vault that you want to download with PowerShell and use on a computer, or some hosted service. How do you get it and actually use it? Well, here, I’ll show you.
Pester and PSScriptAnalyzer are both fundamental tools for testing the effectiveness and correctness of PowerShell scripts, modules, and other PowerShell artifacts. While it is relatively convenient and straightforward to run these tools on a local development workstation, and even on owned/on-prem testing servers, it is somewhat more complicated to execute these tests in your own Microsoft-hosted Visual Studio Team Services environment.
Pester is an open source domain specific language developed originally by Dave Wyatt, which enjoys contributions from a variety of prominent members of the PowerShell community, as well as Microsoft employees on the PowerShell product team. Microsoft is a big enough fan of Pester that it comes with Windows 10, and reference it frequently in talks and written material. Pester is used for PowerShell unit testing.
PSScriptAnalyzer is a static code checker for PowerShell modules and scripts that checks the quality of code by comparing it against a set of rules. The rules are based on PowerShell best practices identified by the PowerShell team at Microsoft and the community. It is shipped with a collection of built-in rules but supports the ability to include or exclude specific rules, and also supports custom rule definitions. PSScriptAnalyzer is an open source project developed originally by the PowerShell team at Microsoft.
Lots of DevOps teams use the above tools together, along with their internally generated standards and style guide, to ensure that PowerShell code that is released into any environment meets their standards. By using Pester to ensure that a piece of code performs the tasks required, using PSScriptAnalyzer to inspect code for general best practice violations, and using a peer review process to validate that code conforms to our standards and style guidelines, you can rigorously test and ensure the quality and functionality of all PowerShell code that you produce.
As part of a PowerShell Release Pipeline, you may store your code in the source control portion of VSTS, hosted by Microsoft. I’d suggest you use the automated build and release components of VSTS to execute a series of tasks before deploying, and to deploy PowerShell code. Two of these tasks are running Pester tests and PSScriptAnalyzer. As a standard, don’t release builds if any part of either of these two tests fail.
In previous versions of VSTS, the hosted build service ran PowerShell 4.x. Because installing modules from the PowerShell Gallery (to get Pester and PSScriptAnalyzer module files so they may be run) requires PowerShell 5.0 or higher, it was necessary to use a third-party configured build step or perform some other hijinks that possibly compromised the integrity of a build. Now that VSTS runs PowerShell 5.0, we can run Pester, PSScriptAnalyzer, and many other helpful modules without exporting them with our other code, or using third-party build steps.