It is up to you to uphold the tenants of idempotency that we have been learning over the course of this book in each DSC Resource you author. The DSC Resource is the last stop in the line of executions that determines whether the current state of the target node is the desired state we described in the DSC configuration script. You must write the code that tests and sets this state in a way that will only change the state of the target node once, the time when the system is not in the desired state.

Significant care must be taken when accomplishing this. You must not change the state of the system if it is in the state we desire. Users of PowerShell DSC expect to be able to run DSC as many times as they want and receive no unintended side effects from doing so. This is accomplished by running near obsessive testing of the current state to ensure we are changing things when we have to.

A good DSC Resource will do one thing, and do that one thing well. When crafting your DSC Resources, you should choose the smallest tasks possible to tackle. For example, consider SQL Server. A DSC Resource could be written that installs and configures SQL Server so that, even if this got very complicated, it could manage both installation and configuration in one resource. However, installing SQL Server is not a simple task when you take into account that it can be installed in a cluster or as part of a recovery set, or a great many other options. How do you handle the long list of options to install SQL Server compared to the equally long list of configuration settings?

Consider the configuration of SQL Server. It is likely that the configuration options of SQL Server will change across versions, but the installation steps won't differ as much. Differing configuration steps or options can be handled in smaller DSC Resources, reducing the amount of work each has to do while enabling the flexibility of choosing when to execute.

Since DSC Resources are PowerShell modules, it is easy to use their built-in discovery methods to share functions and other code artifacts between DSC Resources. You must resist overusing this approach, as it can bite you as time goes on. Let's say two DSC Resources called ExampleResource1 and ExampleResource2 are in the same module called ExampleFooResource. ExampleResource1 has a function that ExampleResource2 borrows to retrieve the same information in order to do its work.

We've created a dependency here that it is now our responsibility to uphold for the life of the DSC Resource. If we change the function in ExampleResource1, it has to change in ExampleResource2. If we don't have some way of tracking this dependency, it can be become hard to troubleshoot breaking this dependency until the DSC Resource is used. If it is a lesser-used function and we don't have a testing practice set up, it could be quite some time before we discover the breakage. While this is not optimal, if you had copy and pasted the code instead of reusing it, you would have to deal with updating code in several files whenever you fixed a bug or updated functionality.

The point being made here is to be aware of the tradeoffs while you develop DSC Resources.

Once you have a solid custom DSC Resource that works and is well-tested (see the following section for advice on testing DSC Resources), we highly recommend contributing it to the community. There are several places to contribute your code to.

Microsoft has a wonderful how-to section on their GitHub repo on how to get started contributing DSC Resources: https://github.com/PowerShell/DscResources/blob/master/CONTRIBUTING.md.

The PowerShell.org site hosts its own GitHub repo you can contribute to here: https://github.com/powershellorg.