I currently have 2 pull servers, one for Prod, the other for all the other environments.
I will most likely go for two more servers, one for each to alleviate the amount of servers connected to one pull server if I see performance degrading once I start reaching 100, 200 and 500 nodes and above registered.
When the number of servers is big, I would even think about splitting the ReportServerWeb for its own pull server to not query directly the database that is used for the configuration.
I cant say there’s a magic number as to how many registered nodes per one pull server, you’ll have to see how the database behaves when you add more and more nodes.
Theres an issue reported on DSC GitHub repo about the database growing quite big
on a daily basis, so have to think about that as well, as at the moment the database resides on C drive
Normally there aren’t a lot of changes during the day, so most of the information logged in that database will be consistency checks (you can increase the time inbetween checks to lower the amount of data logged as well). The log will go up in size when there are errors involved naturally.
For one pull server to server them all, I would make a distinct separation in the names of the configuration files and in the folder names they are located in.
As for instability introduced by changes, that’s not a DSC issue per se, that’s how you work with source control and how you design your branching and merging methodology and how you then use a pipeline to create the mofs (Build Stage) and Deploy the mofs (Release)