PowerShell Modules Rule!
Say you have CI/CD pipelines. You have Azure DevOps (ADO) and are finally using YML pipelines. You're using GitHub Actions. Something else. Whatever you do, you are running some commands on some computer somewhere and are defining them in some way. You are "writing code".?
I'm an ADO man myself. I use YML pipelines all the time. Multi-stage ones defined with templates and parameters being passed to the templates from another pipeline definition. Love it. Works great.?
The issue I have run across is that it is quite easy to use the predefined ADO tasks to do my work. There are tons of them all built in, and you just add them in the order you want them to run and save the file. This is POWERFUL stuff! But there's a huge problem with leaning on them all the time. ?
Problem: "How do you determine if your stuff works?"?
Answer: "You run it and see." ?
This is a perfectly acceptable answer, and one that I have done for years myself. It is time-consuming for both you and the build agents. Those agents are usually shared with other teams, so you are taking their queue spots for your testing. ?
Another thing I find is that it can be pretty embarrassing. You get it to work and show it off, only for folks to see that it took you 98 tries to make it work. Better be ready to hear some giggles.?
What's a better way? POWERSHELL MODULES!?
What is a PowerShell Module??
I'm not going to argue over PowerShell itself. If you don't know what PowerShell is, go here to learn about it: Introduction to PowerShell - Training | Microsoft Learn?
What I will talk about is how you can create your own modules for PowerShell (pwsh). A module is basically a shareable library of functions that you can import into your pwsh session and start using the commands the module has. These are really like extensions of pwsh itself, and there are many available freely in the open source community. These include extensions for?managing Azure resources, working with VMware, administering SQL Server, working with Active Directory, and so on. ?
The cool thing is, you can create your own modules, too! This means you write your own functions, bundle them into a module, and you can share it with others. Learn the basics here: How to Write a PowerShell Script Module - PowerShell | Microsoft Learn?
How do you use them in your CI/CD pipelines??
Here's where things get cool. Sure, you can share your modules with your buddies, but even better is that you can import them into your build agent at runtime and use them there. Instead of filling your pipelines with a bunch of individual scripts (either files that get referenced or those written in-line in the task), you can just run the "import-module" cmdlet, pull down your module, and run those functions. ?
?
?
Why is it better??
Many reasons:?
It will not be easy to move this way, but it's certainly out there and could change the way your team does business. Better collaboration, better quality control on your "pipelines", and a more Agile approach to your work. Do it.?