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:?

  1. The same cmdlets you run on your local machine are the ones that will be run on the build agents during the pipeline execution. This means your own local testing is more likely to work within the pipeline than before.?
  2. Instead of having pipelines with dozens of tasks, you can have a single task that pulls down your module and then runs one cmdlet that does the work. This makes your pipelines cleaner.?
  3. You can do nerdy things like unit testing on your module that you cannot do on your pipelines. A full framework is available to do so: Pester - The ubiquitous test and mock framework for PowerShell | Pester.?
  4. Your module can be treated like its own product by your team, and thus managed in the same Agile approach that other software teams use. Less firefighting and more focused development - seems positive to me.?
  5. You up your own skills. So many of us come from the traditional infrastructure world, having now clues about software development. Why not start a module and get into a more dev-like workflow? That's some resume-boosting magic sauce right there.?

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.?

要查看或添加评论,请登录

Chris S.的更多文章

  • A Question for Data People

    A Question for Data People

    A little background: I'm an old math geek. I took darn near every undergraduate math class offered at both Morehead…

  • Low Code "Revolution"

    Low Code "Revolution"

    I saw an advertisement for Brainboard (Brainboard | Design, Deploy and Manage Multi-Cloud) this morning. I looked into…

    1 条评论
  • A Terrible Terraform Pattern

    A Terrible Terraform Pattern

    Here's a scenario I've seen in multiple enterprises using Azure. Company decides to go with Terraform for all their…

  • A Fundamental Mistake in "DevOps"

    A Fundamental Mistake in "DevOps"

    I've been working as a "DevOps Engineer" for about 8 years, having been an infrastructure guy for about 15 years before…

    1 条评论
  • Right Level of Automation

    Right Level of Automation

    I believe in automation and CI/CD..

  • Skepticism of Competence

    Skepticism of Competence

    My wife said something to me yesterday that I've been really thinking about now for the last 24 hours. She's worked in…

    5 条评论
  • Service Level Agreement Part 3

    Service Level Agreement Part 3

    Part 1 and Part 2 of this series covered the basics of probability and service level agreements. Now it is time to get…

  • Service Level Agreements Part 2

    Service Level Agreements Part 2

    Part 1 Hopefully, folks are feeling "refreshed" after viewing Part 1 of this series. So now let's talk about Service…

  • Probability and SLAs, Part 1

    Probability and SLAs, Part 1

    I recorded this quickly today as a refresher on probability. There are some links in the slides that I go through that…

  • A Series on How to Calculate Service Level Agreements

    A Series on How to Calculate Service Level Agreements

    When you sign up for a specific service, you are promised a percentage of time that the service will be available; this…

社区洞察

其他会员也浏览了