Best practice for dev/prod environment segregation

What would be best practice in Particle for maintaining separate environments for development and production purposes (also possibly others e.g. staging)?
I ask primarily from the angle of integrating with external systems, so separate API keys, webhooks etc., but also from a general administrative point of view from within Particle cloud.

From what I've read there are a few potential candidates - entirely separate accounts, different organizations, distinct products or device groups. I haven't stumbled on any particularly concrete advice though.

Separate accounts would obviously do the job, but if it's possible to cleanly achieve this within a parent account that would probably be preferable.

How have others approached this?

@mjrt Welcome to Particle Community.

I will share here how we approach the points you have raised. This isn't necessarily the best and I would be interested to see how others reply/comment.

First I would say it depends upon what you are aiming to achieve. We are responsible for hardware and software in each device (there are 10 products) - design, development, test and maintenance/support. There is a web app and mobile apps (iOS and Android) - this is the responsibility of another party working for a customer who sponsors, develops a backlog of features and raises tickets from support and acceptance tests. They have PROD and UAT/DEV environments for the web app.

On the Particle device hardware and software side, development is done in sandbox with sandbox devices, when ready for integration with the web app, assigned product devices are created and managed as a group within the product, imaginatively called 'devandtest'. These are on the enterprise account. We haven't split API keys, etc. because the API keys have been product based (historically). There seems little benefit versus the admin effort.

Private repos are used on Github for each product code base. Because we don't have many people developing we operate a simple main branch approach with support tickets merged back in before feature development tickets/user stories.

Hope this helps.

1 Like