This topic contains 1 reply, has 2 voices, and was last updated by
December 5, 2018 at 3:26 pm #128262ParticipantTopics: 12Replies: 33Points: 59Rank: Member
Edit: After reading this post from gaelcolas, most of my questions where answered. Now, to actually implement the solutions...
I am currently working on integrating DSC with a CI/CD pipeline(using VSTS). That concept is pretty new to everyone at work so I was wondering what others did for DSC? I am concentrating on the CI portion for the moment where the goal is to commit the code to VSTS, select the server profile that will then have to be built and have some unit test run on those and, if all test pass, deliver the mof to a fileserver where they can be pushed to the destination(that last part is semi-manual for the moment).
I actually tested what is described here: https://docs.microsoft.com/en-us/powershell/dsc/dsccicd and it works pretty good with their demo code, but it includes some advanced steps that we are not mature enough yet to even think about using(like the ConfigData is generated dynamically. We are far from that, and just studying the custom cmdlet that create the data dynamically will require alot of time) but I did take hints out of it, like using psake .
Any pointers to help build a good pipeline for DSC?
Here is what I have implemented right now, based on what I learned from the url above: A launcher script is edited to select the server profiles that are to be built, then the build for those profile is launched by using psake and a build script(one for every profile selected). In the build script, the required DSC resources are deployed , some very basic pesters tests are run(until we learn to better use pester and make more advanced test). If the tests pass, the mof is created, and if the mof creation is successful, the mof is picked as an artifact and also copied to a folder on a fileserver.
December 7, 2018 at 7:20 am #128604ParticipantTopics: 1Replies: 43Points: 134Rank: Participant
Hey, me again 🙂
First, let me precise on 'dynamically generated configuration data'.
They generate Configuration Document based on rules so that data input is formatted in a way supported by DSC (the ConfigData hashtable).
Datum does something similar by composing the data from a hierarchy (so it generates stuff for you).
If you want a quick pipeline to start with, I'd recommend using the DSC Workshop DscSample: It's more complete and 'modern' than my DscInfraSample, and you can start compiling MOFs straight away. Also the project as examples of running this in VSTS, and Raimund, Jan-Hendrick and myself tend to answer questions/issues (we try).
If you want to adapt this to your environment, you can just put all DscSample folder content into a new repo, and start from there. Most likely you'll change the DSC_ConfigurationData folder content with your environment specifics, and edit the ResolutionPrecedence in Datum.yml to reflect your constraints.
All scripts should just works fine, you might have to edit the PSDepends file if you want to target custom repositories instead of PSGallery, but that's it, it'll produce all DSC artefacts you need (MOF, Checksum, zip modules, Meta Mofs and run the pester tests).
The topic ‘What CI/CD scheme for DSC?’ is closed to new replies.