The community around DSC Resources has been inspiring. The PowerShell Gallery now includes more than 2000 modules/scripts. 181 of those are modules focused on DSC, that collectively include 766 DSC Resources.
With this many building blocks available, it has become easier and faster to get a DSC project through the proof of concept phase to production-ready Windows Servers built using Configuration As Code.
When the author is new to DSC, their first configuration is a complex learning experience. The modules containing DSC Resources often have an /Examples folder with Configuration scripts showing how to use Resources, but they tend to be very specific and demonstrate only the functionality that the Resource was intended to solve. It can be hard to envision an end-to-end scenario-based Configuration. That typically comes later in the maturity model of learning DSC.
So how can we simplify and go faster? We’ve already seen that the community is very good at empowering people to be successful. Sharing examples helps people to look at existing work and identify patterns that can be repeated.
A community repo for DSC Configurations
Last week at the Automation Management Summit 2017, I previewed a new set of project repositories on GitHub. The goal of this work is to document a process for sharing end-to-end scenario-based Configurations.
Here is where to get started:
http://github.com/powershell/dscconfigurations
This project includes three individual repos:
- DSC Configurations
- DSC Configuration Template
- DSC Configuration Tests
The goal of these is to provide guidance and tools to reduce the mean time to minimum viable product by iterating quickly. This was a key point of feedback at least year’s DSC Camp. The Template repo provides an example of how to layout a Configuration project. The Tests repo provides an automated solution to validate a Configuration script using Azure Automation and Azure Virtual Machines.
You will find the documentation in the submodules is still light to non-existant. I will be contributing to these as much as possible. In the mean time the community is welcome to submit Issues and PR’s to get things moving along more quickly. See the DSC Contribution Guidelines for more information.
Process change in the publishing model
I’d like to finish by pointing out an important change in process. With the DSC Resource Kit, today we follow a model where modules are authored and then handed off to the PowerShell team to be hosted in a central repository, and then published to the PowerShell Gallery. We are finding that in this model, we can actually become the bottleneck to release because it can be impossible to match pace with the throughput of so many people doing great authoring work in the community.
So with that in mind, the process for Configuration sharing will be that that the author should continue to host their code in a repo they own. Just like for Resources, they will continue to be the project maintainer. This is only a change to where the code is located on GitHub. Also just like Resources, the author can submit a request to the community for feedback and discuss their work in the monthly DSC Community Call. The end result of their work will still be to publish in the PowerShell Gallery. Additional details such as how to package Configurations and what tags to use will be documented in the DSCConfigurations project repo.
Thank you! I look forward to working together with everyone in the DSC community on DSC Configuration sharing.
Michael Greene