So a week has passed and I’ve had some time to chew on the PowerShell and DevOps Summit. This was my first, although I have previously attended many an Ignite, TechEd, MMS, etc. All in all it was a good event, with a good mix of daunting and and inspiring to make everything worthwhile. Rather than be a generic review of “the venue was great, the food was good”, this post I will highlight some of the key takeaways for me.
The DSC Pull server is changing dramatically
I learned a LOT about this little system while at the Summit while listening to lectures and talking directly to Mark Grey and Travis Plunk. The key take away was the Pull server was never really intended for production use; it was a proof of concept to show what could be created using the published standards yet people like me … well we deployed it. Because of this the Pull Server has gone through a lot of changes in WMF5, even more after WMF5 RTM, and likely still more when 5.1 hits (though this last part is speculation). What does this mean to those of us using DSC Pull servers? Be ready to adapt. Things are going to continue to evolve. I had a good long talk Mark about things I liked, didn’t like, and Utopian dreams of “how great it would be if”. It was refreshing to hear MS program managers completely agree that the configuration of the LCM is too complicated as-is, and map out visions of “simply define your pull server with a shared secret, and the everything else is configured by the pull server”. I don’t know who the final decision makers are, but these talks made me very excited for future builds of DSC if the people at this conference have their way. Other fun notes on the topic:
- The Pull Server for a short while did not function with configuration names when installed on Server Core. Starting in module version 188.8.131.52, this was fixed by swapping out the jet-db (which had some dependencies) for an Exchange-style ese-db. Hope circular logging is enabled.
- The new module no longer accepts “IsComplianceServer $true” as a property. This is great because it caused some configuration issues as well if people tried to use their WMF4.0 configuration with WMF5.0.
- Next release of WMF5.1 will no longer use 1024/sha-1 certificates for authentication. So my personal crusade is being won, or at least that tiny battle has been.
Pester testing is serious business
This was a big theme of the Summit, and I was not the only person caught off guard here: Pester tests need to happen. As we evolve into more automated deployments, we need to evolve into using more automated testing as well. The Summit was loaded with people who had started their DevOps journey and figured “we’ll add testing in later” only to end up doing some major retooling down the line. Many speakers and attendees were advocating putting Pester Test scripts right in the modules to be kept with them in their appropriate git repos. But the theme was the same: learn to use it. Time lost on your first module with a pester test will pay itself back quickly. I may just blog on my own journey, as I’m rather guilty of this abuse here More notes on Pester:
- Many advocate building your Pester Test _first_. It helps define the requirements of the module your about to write, allowing you to write to the test and target your core process. Some were saying it would reduce lines of code simply due to the focus it gives you.
- When generating tests, don’t forget to include invalid resources to ensure the module behaves properly to bad input.
- Special note was made of the $testdrive function, which can create “dummy” volumes that refresh every test.
True DevOps is pretty big at any scale
Sounds weird but its true. An entire company doesn’t not have to be build around DevOps. It can be done per project, workload, or any logical breakdown that fits the business needs. But a proper DevOps model is a big deal and a good amount of work regardless of scale. In fact: that’s one of the benefits of DevOps. It scales really well. A proper DevOps model buys into the idea that if you’re doing it twice, you’re better off automating it once. Thinking about it only from an infrastructure perspective, that means if I want to use DSC to publish Domain controllers, SQL servers, etc. I should have automated process for:
- Pushing my Configurations (how is it getting from the master-branch in git to my Pull server?)
- Build/test environment (how am I testing this … how am I getting Pester results so I know it’s good for production?)
- Retire processes (when it’s time to get rid of a component … have I accounted for the entire process? How do I reclaim resources?)
The agility provided is fantastic, but ONLY after you’ve put the elbow grease in to build out the entire automation stack. It also underscores what’s often stated by not fully grasped: DSC is an automation framework, not a packaged solution. It will need complimentary tools like Jenkins and PSake in order to make this all work, or monetary investment into Chef or Puppet (aka: pay for that prebuilt house instead or tools).
Where do we go from here?
Well for me it adds some focus to future blog posts on my journey and transformation. Expect future posts on the following topics:
- Pester. Yup, I’m going to work on and catalog my experience with this toolset and hopefully making that journey easier for the rest.
- Jenkins and PSake. Looking back at true automation, its time to start looking hard at pulling my repository tighter into my own processes. Again, Ill post my journey and discoveries.