Dev/beta/production vs Products etc in the console

I’d like to set up three fully separate “systems”, each of which containing a bunch of devices, running the same code but in different versions, and cloud apps.

  • The “development” system. That’s where developers (device and cloud) run the most recent builds and everything is moving fast and generally broken …
  • The “beta” system. That’s where friendly users use devices and cloud software that’s not entirely polished and may have bugs
  • The “production” system. Real customers pay real money to use the system, and it better work.

I’m trying to map this into the concepts provided by the Particle console etc. For each of these systems, I want a fully separate message broker (no accidental polluting of customers with development bugs). How would I best do that? Does what Particle calls a Product create a separate name space on the message broker, and I would consider dev / beta / production separate products? Or should I use three different Particle accounts?

Also, from a security perspective, lots of developers should have access to “development” but only very few people should have access to “production”.

Any advice on how to manage this is appreciated …

2 Likes

Hey @jernstlun,

Thanks so much for the thoughtful description as to what your use case is. This is certainly a common request we’ve started to hear from our community of product creators --> more granularity in terms of how to group devices and providing scoped access to those groups.

Your timing could not be better as we are actively planning to begin development of this feature set (we are calling it device grouping) in Q1 of this year! It will certainly not all be released at once, but rather relevant functionality will be built and expanded upon over the course of a few months (Agile development ftw!). I will preface what I am about to share with this: at this point, we are still actively working out implementation details of this functionality, and things are subject to change both in described behaviors and timelines for release.

However, as part of this set of features, we plan to allow you could create groups of devices in your product, then target individual groups to have its own separate released firmware. That should help address your “dev” vs “beta” vs “production” issue. Later on, we will likely layer on access controls on top of product subgroups to provide certain types of users access (or removing access) to certain groups.

For now, if you must unblock yourself, you can “hack” it by creating separate products for each one of these groups as you hypothesized. Although this will become the non-recommended method for handling this once device grouping becomes available.

How does this sound? Is this helpful to you?

Thanks,

Jeff

Hi Jeff, this is good to hear. What are your plans about separate name spaces for what’s happening on the message bus?

@jernstlun – can you tell me a bit more about what you mean by “separate message bus”? What kinds of things would you be looking for?

Here’s the use case: all devices report some measured data on a regular basis by means of Particle.publish. A cloud app listens to those events and, among other things, stores them in a database. If we have three separate systems, the events need to be received by three different (instances of the same) cloud app, and stored in three different databases. It would be nice if we didn’t have to do the filtering about which event gets received by which app instance.

In other words, events raised by developer’s wild hacking should not end up in the production database etc. This won’t happen if we used three different Particle accounts, but I’m not certain that this will also be true in your proposal.

OK @jernstlun I totally gotcha. As part of the set of features being planned as well, you will have the ability to segment your event stream by group. That is, your back-end could narrow down the event firehose to just the group it cares about. Sound good?

@jeiden: that sounds good. Thanks.