Tuesday, 3 July 2018
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
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
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.