Automation and testing

Experimenting with PowerShell Pester testing as part of DSC publishing

I like automation. I like PowerShell. I like automation with PowerShell. If you’ve read the other posts within this blog, you will have seen PowerShell in use a fair amount. Whether it’s just using a cmdlet to configure something or doing a small script, you will see I use it heavily. In the post AD Sites and Services … Not Again! I was looking at using PowerShell DSC to configure AD Sites and Services, something particularly useful in a multi-forest environment where each forest should know about all the sites.

As part of using PowerShell DSC for configuring AD Sites and Services, I have submitted some additional work to modules, created pull requests to get the additional features included and noticed the sheer amount of process that you have to go through to get a PR merged.

Although at first this seemed a real pain, the more I worked with it, the more I liked it. Having the reviews and full testing within an environment is nothing new to developers. As an infrastructure engineer at heart, for a long time I was just a write a script and run a scheduled task person. In a previous role, I changed this to be store it in source control, use TeamCity to run the tasks, grabbing the script(s) from GitHub.

When attempting to use DSC for AD Sites and Services, I came across a conundrum. In a tiered admin model, how do I prevent a low tier account making changes to the configuration? Well, this is actually fairly simple. Using branches and branch policy, it can be set up so that users create a branch, do their work, commit and then create a Pull Request to merge the changes in to master. A tier-0 type account has to review and approve these PRs, therefore a tier-0 level account initiates the configuration change.

This is all well and good but given that this level of change can be impactful, how can we make sure that everyone is coding to similar standards? How can we know that the code that has been written should work without issue? This is where testing comes in to its own. A popular solution for PowerShell testing is Pester. I wanted to make sure that the PowerShell scripts being written were all done using certain standards, such as not using an alias of a command (use Where-Object not where). Well, to try and make sure that we can push to master without breaking everything, as well as a review of the code, as part of a branch policy in Azure DevOps, I also run a Pipeline to validate everything. This pipeline can be found on GitHub.

So what do I actually do? Well I run through and use MarkdownLint to ensure that the Markdown files are all formatted to a standard. I use PowerShell Script Analyzer to make sure we follow certain rules. PSSA is run using Invoke-Pester and tested against all the rules. Feel free to review the repository and provide feedback. The idea is that this repo will be a general testing repo for all my PowerShell scripts.

On top of what’s there, I will also do a test to ensure that the DSC configs will compile without error before having them pushed to Azure Automation. This way we should be fairly confident that what gets pushed should work.

I am always looking for additional ways to test scripts to ensure all is happy. If you have any suggestions feel free to get in touch.

 

Leave a Reply

Your email address will not be published. Required fields are marked *