I keep two patch policies for each app. One test, one production. Scoped to "Test" and "Production" groups. "Test" is a static group, "Production" is a smart group that basically just says "not a member of Test" and "Not a server". Patch policies are smart enough to only include machines in the scope that have the app, so something like Excel will only upgrade machines that have Excel (usually installed at build time or via Self-Service), and won't force Excel onto machines that don't already have it.

Just go and adjust the version specified for each group as your test cycle finishes. Works fine. I don't ever touch the scopes themselves that way.

Excellent, thanks for the response! I knew I was missing the forrest for the trees. Essentially each group, test and production, could have different versions of the update attached to them until I'm ready to go to production. When I'm ready to roll out to production, I just need to go in and change the version applied to production.

My pleasure. Took me a few weeks to get used to the "new way" of doing things, but once I adjusted, it makes moving from "Test" to "Production" status a piece of cake. Just go into the policy, hit edit, choose the new version from the drop-down, and save. Nice and fast.

Only real gripe I have with Patch Management right now is that it doesn't cover enough. I've added in a bunch of 3rd party apps, but the community-supplied ones often aren't updated frequently (Garage Band hasn't been on 10.2 for months, for example), and I haven't had time to set up my own server to keep them updated myself.