Hello!

The past few months I’ve been improving the pipeline I use to build and publish a Visual Studio Extension that basically updates the module version number and publishes it to the PowerShell gallery. You can see the status of the pipeline here!

The build and release pipeline are publicly available to view here.

I use a single pipeline because once I’ve run the tests there’s no need to fret about whether or not I hold off from pushing a later version. Continuous Deployment FTW. But in addition to CD, I’m going for something I have come up myself: “Eventual Improvement”. What this basically means is that you have a pipeline that works to deliver an MVP in an MVP-style, and then once development has settled down and you don’t anticipate to make many more changes to the code for the time being, you can improve the pipeline. For example I have added the tests to run over more than one type of build agent. As all the tests run successfully on these build agents, I’m confident to say that the task works on

• Hosted 2019
• Hosted 2017
• Windows Containers
• Linux Ubuntu 1604
• Linux Ubuntu 1804
• mac OS High Sierra

and whilst there’s more agent types than that, I did only ever set it up to run on the hosted 2017 build agent and a locally running build agent.

And so recently I have decided to improve the testing around the code. Currently there is not 100% test coverage. Still, one test is an infinite improvement over zero tests, and this is because I have a framework to create tests against. Initially the tests were merely PowerShell scripts, and that if the scripts did not fail in the build then everything was golden. And again thanks to “Eventual Improvement” I decided to alter the tests to run in the Pester framework. Here I could ensure that the scripts do not throw, and eventually, I could add more asserts much more easily. Plus I could add the results to the test results tab in Azure DevOps, if only I can find a way to consolidate the results that are across 6 or 7 disparate build agents.

However, running Pester tests in Linux proved to be a little more tricky. Typically you install Nuget as a package provider on the Windows agents and then install the module like so -

Install-PackageProvider -Name NuGet -Force -Scope CurrentUser
Install-Module Pester -MinimumVersion 4.3.1 -Force -SkipPublisherCheck -Scope CurrentUser

However this plainly does not work on Linux. So after a little bit of faffing about with Linux, this will work -

Find-Module pester -Repository psgallery | Install-Module -MinimumVersion 4.3.1 -Force -SkipPublisherCheck -Scope CurrentUser

So OK, not really all that much more tricky. In fact, quite a lot more straightforward. But still useful to know nonetheless.