Some Munki admins use sharding to roll out to various portions of their fleet. Most versions of sharding create a random-looking (but not actually random) integer either between 0 and 99 or 1 and 100 that is based on a hash of the Mac’s serial number.

Where that can be tricky is when you want to use it in conjunction with catalogs, which you likely do, especially if you have a catalog for early testers and one for VIPs or C-level execs.

I’ve created a fork of munki-facts-conditions with a shard.py you can adapt for your own situation, based on your own catalogs and what shards you want to assign to them:
github.com/aysiu/munki-facts-conditions/blob/main/facts/shard.py

In the linked example, the development catalog always gets a shard of 0, regardless of its serial number, the testing catalog always gets a shard betwen 1 and 10 inclusive, and the execs catalog always gets a shard of 99.

Any other catalog gets some number assigned between 11 and 98 inclusive based on their serial number.

But you can do your own fork of my fork, and adjust the names of the catalogs and the various number thresholds.