When we first started looking at DSC for production use, we were using the same process and modules that came from Steven Murawski and Stack Exchange. There are several blog posts talking about this tooling, but here’s a high level overview of what our pipeline looked like originally:
- TeamCity is our Continuous Integration server; it monitors our DSC source control repository and kicks off the build process.
- Stack Exchange / PowerShell.org DSC tooling modules were used to take the data from source control and run tests, then produce configuration documents and resource module zip files.
- Octopus Deploy was used to transfer these artifacts out to one or more DSC pull servers.
- DSC pull servers delivered the bits down to clients.
This works, but what was missing was the ability to define environments (dev/test/prod/etc), and to version the configurations and modules in such a way that they could be promoted through these environments in our pipeline.
To address this, we’re trying out something new. We’re cutting out the middle-man of a DSC pull server, and having Octopus Deploy deliver our DSC configurations and resources directly to the endpoints. As far as DSC’s Local Configuration Manager is concerned, we’ve switched to a Push model. Really, though, that depends on how the Octopus Deploy Tentacle is running (which can be set up for either push or pull, just like the LCM.)
With this setup, we can promote versions of DSC configurations through our environments using the same mechanism that’s already in place for our application and website code. We can also leverage Octopus Deploy’s variable-scoping functionality to control our DSC configurations; these Octopus Deploy variables are essentially taking the place of the entire DscConfiguration module in the new pipeline:
Now, Octopus Deploy’s dashboard shows us exactly which configuration version is deployed to each environment:
We’re still experimenting with this approach, but we’re getting pretty positive results so far. A nice perk for our customers is that they have fewer new tools to learn when we’re first setting things up; they don’t have to grok both Octopus Deploy’s variables / environments concepts, as well as a separate solution doing the same thing for DSC.