Tuesday, 3 July 2018

Testing Azure Automation Runbooks using Pester

If you’re using Azure Automation Runbooks for automation, you may find yourself writing code that is not testable. To test your code, it needs to be in functions. Sure, you should break out all of your repeatable, reusable code into functions and save them as separate Runbooks, or a collection of functions that you can “Dot source” into your other Runbooks.

But, Runbooks really are functions, they are just not declared as functions. You have a single file, that accepts parameters, and executes code.

That is a function! Let’s make it testable.

Take this Runbook: Test-Script.ps1

And this Pester Test Test-Script.tests.ps1

The Pester Tests will generate this temporary file, which can be dot-sourced in as a function:

Friday, 15 June 2018

TechSnips: Your Chance to Become a More Successful Tech Professional

We're geeks, right? We love tinkering with tech and figuring out better ways to solve problems. How cool would it be if lots of us could come together under one platform and share our hard-earned knowledge with everyone else via technical demo screencasts? I'm glad you asked!

I've recently launched an IT career development platform called TechSnips. First and foremost, TechSnips is not a Pluralsight, Udemy or LinkedIn Learning. We don't do courses; we do snips. Snips are short (1-10) minute screencasts with absolutely no slides of any kind. Its purpose is to deliver exactly what IT pros, system administrators and other technology professionals need right now. We skip over all of the fluff.

Because of this short format, it's a lot easier to get started contributing if you're new to putting yourself out there in a tech community. You will learn presentation skills through feedback from myself and your peers, you'll be a member of our growing community and get access to our Slack channel, you'll have some great content to put on your resume and you will get paid in monthly royalties!

Joining has a ton of upsides but you've got to be willing to put yourself out there.

I'm looking for contributors that can help myself and the dozens of other contributors build the TechSnips content library. As of now, we need to fill a lot of holes so the types of screencasts will most likely be up to you. As long the content fits in the snip format (which you'll get more info on the signup page), the world is your oyster. FYI: We needs lots of DevOps stuff!

If you're interested, please sign up! You'll be asked to do a quick audition and once approved, you'll be part of the TechSnips Contributor community! I look forward to seeing what new content you can come up with and how teaching others can help yours and others' IT careers flourish!

Thursday, 31 May 2018

Writing Resuable, Modular DSC Configurations

A few weeks go I posted about writing better DSC Configurations with Configuration Data. Really, this was just the start of the journey. Ideally, you want to want to pull your Configuration Data from your CMDB, but often tools or processes are missing to get your configuration management up to this level of integration. So let's go with something 90% of the way there. Now this in-between state is nothing to scoff at. You can run with this if you need to. Let's take a look.

When you are building your configuration, you have two essential parts. Your Configuration, the .ps1 file that is compiled to generate MOFs and the Configuration Data, the .psd1 file that is used to provide data to the configuration. You want to modify the Configuration file as infrequently as possible, modifying this file is bound to cause errors and issues (People make mistakes). Also, you want the Configuration Data to be modular, so multiple people can work on it at the same time without any chance of conflicts.

So, let's build a succinct and reusable configuration. Take a look at the below example:

The small block of code above installs all the features for any given node, based on its role. The node is defined like this:

As you can see, the Roles property is an array. This allows you to specify multiple roles for a given node, making it extremely powerful and allows your roles to be more modular.

Let's take a look at the role definition.

The role definition defines which features are associated with the role.

Now let's discuss how you can bring all this together. The Configuration Data is made of of two major parts. The AllNodes block and the other Configuration Data. This is sometimes called Non-node Data. Ignore that name, we going to use it to store all sorts of information. Take a look at the below code and file structure.

The script creates a hashtable for the configuration, then pulls in each of the Nodes that are represented in individual files. Then it pulls in all of the additional configuration data, such as domain and site information, finally the role information is imported, building a single configuration data file that can be used to compile your MOFs.

What are your thoughts on this type of modular DSC configuration?

Did you happen to notice the naming convention applied to resource names? That allows you to dynamically build DependsOn blocks.