Best practice for testing yearly OSX releases with test user group before releasing to production.

For us, the test group does not get to test a new OS release without IT having verified that the vendor supports the new OS. Sometimes that means day 1 support from the vendor, sometimes that means waiting a week or two and in worst cases, months. However once the most critical applications are compatible, we can proceed to make it available to end users via Self Service. At that point, it's not really about testing compatibility, but seeing what issues may come up. Every environment is different though. We definitely don't back up though. If we need to roll back, we can grab the files off the computer and re-image. Some places are like the wild west and you can only advise but people will still fail to heed any warnings you give them.

Thanks for the Reply! I think what we are going to do is Use Time machine to take a snapshot of the systems before upgrading to 10.11, Set a limited testing time of about 1 week, In this time we will allow them to roll back to the 10.10.5 snapshot TM took last, make them aware that it will be like setting the computer back a week , what we still need to hammer out is how to manage testing feedback. what we want them to test and how, ect

Just a thought, Cant I do this with Policy or an extension attribute that could be scoped to a Static computer group for testers and hosted in self service? sort of a 1 click backup button option ?

@Gabriel.Duff There are all sorts of things that you can do to initiate backups or almost any number of other things if you're good at scripting (all of this I'm sure you know).

In my personal opinion, I recommend NOT using any populace as first run Guinea Pigs. Like @bpavlov mentions, use test systems to make sure that you've got basic functionality all sorted out first. Once you've got full functionality, then begin rolling out to test groups as a precursor to a final implementation. You're going to turn off your test group if you their production machines keep blowing up with basic issues that take hours to recover from. This will also help from ever having to "roll back" to any previous system. I've always had the mantra that you should ALWAYS move forward. If you're moving back then someone didn't do their job and the users paid the price. Not to mention the amount of work and testing you're going to be looking at to automate the process you're wondering about.

(Side note: I've always believed that you should backup files and services, not entire systems where possible.)

As for your specific question, I've heard of organizations using networked time machine backups to facilitate this kind of request. Yet it seems rather complicated, with a lot of heavy lifting done by the test machine, local file servers and whoever is scripting it. Enterprise backup solutions like CrashPlan are really built to provide this type of functionality as opposed to something like Time Machine. Not that I'd expect you to swap form TM backups to Code42 just to test OS releases...