Just offering a slightly different viewpoint to @vedecoid.
Over multiple projects, I’ve avoided unblessing whereever possible. Our units are installed at remote sites (for dev and production), so unblessing and blinking steps up are generally impractical. Thus, Option 1 is our preferred approach.
We have staging areas in dev and in production. Release candidates will move through both areas before being released to full production. Releases that contain test code will sometimes end up in production-staging. On our currrent project, we have around 10 different production device groups, each potentially running a different version.
It’s really important that you can capture bugs along the way. Since you’ll lose access to the logging console on production devices (except for a small set), you need to be confident that your own internal logging will sufficiently capture any abnormal behaviour. Electric Imp use a “black-box” to capture connectivity diagnostics on devices. From what I understand, it’s stored in flash for upload at the next connection. Adopting a similar approach for your own purposes can be helpful. If you can spare the cycles on your device, get it to log behaviour in flash. This can be uploaded later, only if you feel you need it. This keeps data usage to a minimum on production devices.