Geeks 4 Data

Listen up dudes! We need to write some unit tests for all these PowerShell functions we have been writing. Why? Because we need to make sure our code does what we think it does and only what we think it does. Yeah, I know we test the functions manually when we use them but we are pretty limited in our ability to monitor what our code is doing under-the-hood unless we get some kind of verbose output. Even then, we don't know what we don't know. With the use of a testing framework (like Pester) we can test each function and isolate its inputs and outputs to make sure that thing does only what it is told! If you have got this far, like I did a while ago, and you have watched a few intro videos (like this one  https://www.youtube.com/watch?v=gssAtCeMOoo  and this one  https://www.youtube.com/watch?v=0fFrWIxVDl0  ) and you have downloaded Pester from GitHub ( https://github.com/pester/Pester ) and you have copied the extracted folder to the PowerShell modules directory...

Ok, let me just say up front, the Pull Server rocks! The centralised management and scale that it delivers is great. It is all good dude, but... When learning how to use a Pull Server to distribute node configuration you have to keep a few things in mind in order to make things work. This is what I have learnt so far: The event log is your friend, get to know it well There is a resource available to help diagnose DSC issues called xDscDiagnostics - it is a good place to start. Remember that publishing a new configuration to the pull server does not mean it is just going to get applied on the target the next time the target node LCM fires up, it depends what the state of the Pending Configuration is. Remove-DscConfigurationDocument  can be used to pull the plug on a misbehaving config Removing a misbehaving config will not remove a misbehaving Resource (ermm, deleting the resource folder on the target node seems an easy way to fix this but not necessarily the right w...

I love source control (not agape love or anything like it but I really do dig it). It gives me great peace of mind knowing that if I make a stupid mistake in my code (and let's face it, it's gonna happen) I can compare the current version of the code with any previous version and revert back if I need to. Thing is, I don't like having to do that - I want my code to be sharp, readable, cool but most of all right. And I want this to be the case before I check it in (commit). The problem is that there is not always a bud available who has the time and is in the frame of mind to review my code when I need him\her to. Don't even think about scheduling code reviews, that is just a pain in the rectum - it messes with my mojo when someone interrupts me when I am in the zone just because 4:30 has arrived on their watch. Then there is the problem of dudes who haven't read Code Complete and like to write 2000 line functions because they haven't learnt abstraction. Who ...

One of the first things I have learnt working with DSC is that the Local Configuration Manager (LCM) does things on a schedule and that it is quite a patient little service. This is most obvious in a Pull server setup. I copy a config (and checksum file) to the Pull server and then wonder why nothing is happening on the target node. The first thing that comes to mind is "my Pull server ain't configured right". So, naturally I have a look at the LCM on the target node: PS   C:\>Get-DscLocalConfigurationManager -CimSession $target_node The LCM says it is configured for Pull and looks happy so why the heck is my configuration not being applied? Well, the answer is in the RefreshFrequencyMins property of the LCM (which is 30 by default). I could end up waiting for 30 minutes for anything to happen, or I could just tell the LCM to get on with it: PS C:\>Update-DscConfiguration -ComputerName $target_node That will output some details on the job that is carrying ...

Four years ago I sat in a conference room in Barcelona and listened to a Gartner analyst talk about the emerging practice of DevOps. I was excited because the conflict between developers and the infrastructure\operations guys was not new to me. I was sitting next to my manager, the Group IT Manager, and fully expected to have a really positive discussion about it after. We both walked away scratching our heads. The problem with paradigm shifts in IT is that the success or uptake of the change really depends on who delivers the message. If it couched in too much highfalutin mumbo-jumbo then the people who really make it happen (the folks doing the daily grind) just miss it and carry on as normal, or they get it wrong. Today I believe I understand what DevOps is (at least from one perspective) and the thing that has helped me to understand it, is Powershell Desired State Configuration. DSC is the embodiment of declarative configuration automation for IT infrastructure. In learning ho...