Some time ago my team was involved in a reorg (I’ll skip the boring details), the end result is that I am now working on a different (and new) service and I am transitioning to a new role. This seemed a good moment to do some spring cleaning and reorganize my tools/scripts/modules etc… Over the years I have built a good amount of powershell scripts and modules (among other tools), most of them targeted for my and my colleagues specific work and role but I wanted to see if there was some I could instead share to hopefully help someone else. It took some time, I ended up deleting a number of old scripts no longer relevant (well, I couldn’t really delete them, they are just archived in a private GitHub repo 😉) and I have reworked some of my modules and functions into a collection hopefully worth sharing. The result is three new modules you can download either from the Powershell Gallery or from GitHub (and contributions are welcome, should you feel generous enough to open issues or send me a pull request 😊). PSToolbox (GitHub, Powershell Gallery) is a collection of functions for every day operations, things like…
-
-
Publish module to Powershell Gallery from Azure Pipelines
Now that I have my module on Github and built the module on Azure Pipelines, I want to publish it to the Powershell Gallery. The first step it of course to create a free account; once you have the account you can head to your profile, click on API Keys and then Create: The Create dialog allows to choose the key name, the expiration and very important, the scope (what permission the key will have on the Gallery) and which packages the key is allowed to control through Global Pattern. In my case I want the key to expire every year, I want the key to grant permission to publish new packages and update existing ones and I want this key to be used only for LSE modules: notice I used LSE* as Global Pattern, this way this same key will allow me to publish and manage new packages as long as their name begins with LSE. Azure Pipelines allows to securely store secrets (passwords and keys) as variables, if you want to do so you can use the Variables tab in your Pipeline then click the padlock icon: Anyway I prefer to store the key in Azure KeyVault since…
-
Test Azure custom modules with Pester
Before I go too far along with building my LSECosmos module I must add proper tests. Just as a quick refresher (or to get some context if you’re not familiar with the concept), here are some pointers about Test Driven Development and Unit Testing: Test Driven Development (Wikipedia) Unit Testing (Wikipedia) Software Testing Fundamentals While it is relatively straightforward to test simple scripts (we would likely manually run the script testing a 2-3 core scenarios to make sure nothing terrible happens), things can get complicated fairly quickly with longer scripts or modules, especially when they are using a variety of cmdlets to take actions (think about Azure resources for example, or any other system-wide on-prem operation), need to pass data and objects back and forth between calls and so on. If you have written enough lines of code (no matter the language/tool you use), I bet you can remember at least one occasion where you decided to make an apparently small and innocent change to a well working piece of software an all hell broke loose 😵. I recently came across this meme on Facebook, it sums it up nicely 😅 (thanks to CodeChef for sharing): At its core proper…
-
CosmosDb module
CosmosDb is a non-relational, distributed database you can to build highly scalable, global applications in Azure. It is: – Always on – Offers throughput scalability – Low latency, guaranteed – No schema or indexes management – Globally distributed – Enterprise ready – Use popular no-Sql APIs https://docs.microsoft.com/en-us/azure/cosmos-db/introduction It’s all great from a development perspective, but when it comes to management things are a bit different. CosmosDb can be managed to a certain extent through Azure CLI but as of this writing there is no Powershell module available: I admit I have only superficially explored the existing modules and while it is great to see the Powershell Community sharing modules and scripts, it would probably be nice to have an official module by Microsoft as many other Resource Provider offer. This is a good opportunity though to continue exploring the topic I have introduced in my previous post about calling Resource Provider actions and since these script will likely be reused (I can actually use them at work), why not build a reusable module? Module basics Writing a Windows Powershell Module is a good point to start to get an overview of this topic; I’ll write a script module and I’ll…