Few bits

[gaelcolas]

I do have a Blog post in the making about that, but probably won't be published before the new year. Few quick points:

• IMO Unit tests are tied to their context, aka layer of abstraction
• You will likely have Composite resources of your making, so you probably want to test at different layers of abstraction: Testing the custom resources (unit + integration), Testing the composite resources (unit + integration), testing the top level configuration
• You may need to test your configuration data to some degree
• Your Build step should Compile MOF files, even if your Unit tests on your config script passes, the MOF Compilation may fail, for instance because of Config Data issue
• You may need to test the deployment of individual roles, and the aggregation of roles into a service... (i.e. Deploying a single DC then Deploying multiple DC with different roles)
• From your diagram looks like you're using the GUID way. You can also use Config Name instead (as in 1 Config Name per role and preferably 1 role per machine)
• Is your plan to have your whole environment managed through that pipeline, or you assume some of it will sit outside of it? (You have no PKI listed btw)

Here you go for a late brain dump. You might want to look at https://github.com/PowerShellOrg/DSC for some tooling. I'm refreshing it slightly here and will try to submit a PR Next year.

Good luck and please share your journey :)

[gaelcolas]

Also, that would do a great whitepaper along with this one (which would need some love): DSC Pull Server. Have you checked @mgreenegit Demo_CI project

[stefanstranger]

Hi Gael,

Thanks for taking the time to respond to my 'journey' :-)

Let me reply to your points one by one.

• IMO Unit tests are tied to their context, aka layer of abstraction [stefan]: I agree
• You will likely have Composite resources of your making, so you probably want to test at different layers of abstraction: Testing the custom resources (unit + integration), Testing the composite resources (unit + integration), testing the top level configuration [stefan] : I agree that creating unit tests for DSC (Composite) Resources would also become part of the Release Pipeline. Creating these tests are probably more straight forward compared to creating unit tests for Configuration Scripts.
• You may need to test your configuration data to some degree [stefan]: the question is to what degree and what should be tested :-)
• Your Build step should Compile MOF files, even if your Unit tests on your config script passes, the MOF Compilation may fail, for instance because of Config Data issue [stefan]: great point. I leared from a developer that in a build you compile your 'code' and test if it works. But I also learned that other have other ideas on what should be done where in the release pipeline.
• You may need to test the deployment of individual roles, and the aggregation of roles into a service... (i.e. Deploying a single DC then Deploying multiple DC with different roles) [stefan]: so you think during the test a 'real' DSC Configuration deployment needs to be executed? What to do with partial DSC configurations?
• From your diagram looks like you're using the GUID way. You can also use Config Name instead (as in 1 Config Name per role and preferably 1 role per machine) [stefan]: I need to find more information about this. Do you have a link for me?
• Is your plan to have your whole environment managed through that pipeline, or you assume some of it will sit outside of it? (You have no PKI listed btw) [stefan]: no I don't plan to have the whole environment being managed by the\this release pipeline at the moment. For the moment the release pipeline is focussed to the DSC deployment. Can you elaborate on the missing PKI? What do you want me to add?

And yes I checked @mgreenedit project. I also have internally contact with him about this topic :-)

Disclamer: I'm not a developer but trying to learn more :-) Some of the terminology used in the DevOps world is new to me.

[gaelcolas]

In Turn:

• [stefan]: the question is to what degree and what should be tested :-) I think you will only find out when you start having your configuration data in shape (much later in the process). I personally don't test it much (not enough) right now, but I catch most of the errors either at MOF compilation or Integration testing level. I'd prefer spotting some stuff earlier (i.e. Null values) to shorten the feedback loop, but I'll get to that eventually next year ;)
• [stefan]: so you think during the test a 'real' DSC Configuration deployment needs to be executed? Definitely. You'd need to test that the configuration works in itself (so is deployed) and then that the result is what you expect. In other terms: Can I deploy the configuration -> Yes; Is the service configured as I expect based on that configuration -> Yes; SUCESS The other thing to bear in mind is that a service (file sharing for instance) is a composition of different components on different nodes: i.e. AD for auth + File Sharing. It depends how you design your services and where you place your boundaries
• What to do with partial DSC configurations? I completely agree with Steven Murawski's point of view here: avoid them: http://stevenmurawski.com/powershell/2016/03/dsc-partial-configurations-are-the-devil's-workshop/ But I see composite resource as almost mandatory IMO
• [stefan]: I need to find more information about this. Do you have a link for me? Yep the PowerShell documentation is a good intro to this.
• [stefan]: no I don't plan to have the whole environment being managed by the\this release pipeline at the moment. For the moment the release pipeline is focussed to the DSC deployment. Can you elaborate on the missing PKI? What do you want me to add? If you want to secure your mof you'll need certificates, and you should use one for your Pull Server auth. You can workaround it in a Lab, but that would be a less realistic implementation.

Do read Steve's post about being realistic with your expectations, feel free to browse my article here to get more info about how I use Test-Kitchen in my DSC pipeline (this is only the first part, there's more to come but I'm very busy until at least January).

Re- your disclaimer... This is beyond just Development. Dev is the new Ops anyway, we're applying Dev principle and practices to an indispensable Ops mindset. We're not replacing anything IMO, we're evolving...