Share via

PowerShell Desired State Configuration for DevOps and ALM Practitioners v1

  • Article

We are pleased to announce that the first version of the PowerShell Desired State Configuration for DevOps and ALM Practitioners guidance has shipped.

what’s included?

image posters image

Guidance

Posters

Samples

where is the stuff?

image image

the team

A special THANK YOU to the team of ALM Rangers who volunteered their personal time and contributed their real-world experience to deliver this solution: Bill Heys, Brian Blackman, Giulio Vian, Hamid Shahid, Jahangeer, Jeff Levinson, Jim Szubryt, Keith Bankston, Mathias Olausson, Mattias Skold, Richard Fennell, Rob Jarratt, Rui Melo, Shawn Cicoria, Tiago Pascoal Willy-Peter Schaub, and Vinicius Hana Scardazzi

Did I forget anyone? If yes, please ping me with a bang (!)

this is what our product owner said in the foreword

We hear the term “DevOps” frequently in current press, popular books, and presentations from many product vendors. The DevOps concept focuses on how to build deep integration between Development and Operations, organizations who have historically been at odds. This has been brought about, in part, by the need to increase the velocity of delivery from development into production, while ensuring that the Production environments are always running.

Many of the difficulties are well understood, and documented in those same DevOps articles, books and presentations. One of the big problems to solve is ensuring that everyone is working with the same processes, systems, and tools, throughout the product development and delivery cycle.

The Development team needs to know that changes they deliver to Operations will work in Production, so they need to develop and test their changes in environments that match Production systems. The same automation scripts Operations use in Production should be used in the early test VMs and pre-Production test labs. Any changes to the system that were required by the Developers would be made in the automation scripts directly, and included with their updates. Those scripts then document the modified environment, improving the ability to review changes with the Operations team before they would be applied.

The Operations team needs to know that what they are deploying has already been proven to work in Production, or spend critical time re-validating changes during “outage windows”. Automating system setup and configuration is not new, but historically the scripts were monolithic, requiring the Operations team to modify the core code when moving from test labs into Production. Separating the actions in the automation code from the environmental data (such as server names & accounts) simplifies the updates, and reduces the risk of error. In addition, by restricting changes to what is in automation scripts, updates can be validated in advance, rolled back if something bad occurs, and all common systems can be ensured to be consistent.

The development of PowerShell Desired State Configuration (DSC) was based in part on these requirements. PowerShell DSC is a set of extensions to the PowerShell language that enable creating PowerShell functions that are repeatable, and by design scripts into are separated into components for repeatable actions, structural configuration, and environmental data. In PowerShell DSC, the separate components are called Resources, Configurations, Configuration Data. This separation of action from structure from data is a new way of scripting, and requires changes in thinking. PowerShell is new to most Developers, and the style of coding is new to experienced PowerShell users.

This is not simply changing about the structure of automation scripts. With any system built using PowerShell DSC Configurations, the PowerShell DSC engine periodically tests the current state of the machine against the desired state, monitoring and alerting, and optionally automatically correcting configuration drift. Configuration changes that do not come via changes to the PowerShell DSC code are quickly identified and resolved. In addition, Visual Studio is integrating PowerShell DSC into the Development process and the release management pipeline – something that will be covered in future articles. Packages built using Visual Studio can now include the DSC resources and configurations needed to deploy the system.

The change to DevOps has broad impact, and we cannot cover it all in one place. This document focuses on getting users familiar with PowerShell DSC. For those unfamiliar with PowerShell, it gives some guidance on where and how to learn the capabilities of PowerShell, and leverage it in their coding projects. For those already familiar with PowerShell, it explains how DSC is different, and how to leverage the tools and contributions from others to rapidly adopt these concepts when developing their own PowerShell DSC Resources and Configurations. It also directs users to repositories of open-source repositories where they will find DSC Resources and examples that are available for their use, which will help speed the adoption of DSC.

Integration of the code required for a smooth transition between Development and Operations is becoming a reality in many places. While PowerShell DSC helps to enable this, it does require some changes to the design and development of automation scripts. We hope this document will make the transition faster and easier.

Keith Bankston – Senior Program Manager, WSSC WS PM USA
DSCN7539Pierre, Keith and Willy @ TR19.

please send candid feedback!

We can’t wait to hear from you, and learn more about your experience using the add-in. Here are some ways to connect with us:

  • Add a comment below.
  • Ask a question on the respective CodePlex discussion forum.
  • Contact me on my blog.

Comments

  • Anonymous
    October 22, 2014
    It's nice to see some practical guidance around using PowerShell for DevOps tasks.  I remember having to use batch files and in some cases (remedially written) PS scripts run over MS Deploy to push and configure websites.  Having more of a standard for how to perform these tasks helps tremendously.  It also allows administrators to utilize native features of Windows Server without having to install additional language dependencies like Ruby (used for both Puppet and Chef).  Not to take anything away from those products or the language itself--they are certainly useful.  That being said, Windows Server does not ship with Ruby / Puppet / Chef pre-installed by default.  :) I'm excited to see what gets revealed in forthcoming versions!