I’m curious what people do when they want to run development code on a set of production devices. Basically I have some code I want to push to my engineering team so they can run it on a hand full of devices. The two options I can see are:
Promote the code and push it out to a new Production Group
OR
Unbless the production devices, blink them up into a DEV group.
With option 1, I now have test code interleaved with my production deployments which just seems like a bad idea. With option 2, I have to add the burden of unblessing/blinkup to the engineering team when they set-up a test group.
Am I missing an option? How do other people handle this?
we basically use option 2.
The different development stages are
As many development device groups under 1 product used by developers (r&d) as needed to ‘do their thing’. Ranging from specialised device groups focussing on one aspect of the full code (eg to develop and test specific classes) to fully ‘combined’ device group to develop the glue logic between all classes. .
Production Staging device group in the development zone that is pulled together by Builder from the different device groups out of 1. including the necessary glue logic. This is the code that eventually gets promoted. No code changes are made in this particular group. It’s a pure combination stage of the groups under 1. (every sub-group has their own repo under github). The agent and device code in this group only consists out of @include (once) and #require statements.Testers and pilot customers use development devices out of this group. If it wasn’t set up like that from the start, unblessing is needed (but pretty straithforward and less work then creating and blessing a special production group)
Test and production groups that deploy the promoted code from 2.
this approach has the advantage that you can @include specific branches from eg a class which avoids breaking production code when a class evolves to more expanded versions.
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.