Hi @tmigone ,
Thanks for coming back to me (and sorry for the delay - was off yesterday!).
The fundamental desire is for releases that can be promoted through different groups of devices in a pipeline. Releases staged in a sense of not just applying to the full group of devices automatically, but applying to different groups of devices automatically based on levels of confidence in the release. Think of a release being tagged as ALPHA → BETA → PROD, with devices configured to track different phases, and promotion between these phases being a manual decision.
Ideally, the actual releasing or deployment would not be done by hand (i.e. handpicking test devices or updating static pins). We would just tag a release as the BETA release and it would deploy to the BETA devices.
Applications for Device Cohorts
Creating multiple applications would meet our requirements to some degree. Is this the approach most in line with Balena’s vision, as we’d like to build a fitting approach?
I was under the impression that using differing applications when they actually represent the same application and codebase(s) was not in line with what Balena advocated. This interpretation is based on comments such as:
and I received similar guidance here:
I see two drawbacks with using applications to manage different device cohorts for the same application:
- An exploding amount of applications in the Balena dashboard. This is further exacerbated by existing issues we have in managing diversity, and that currently some of our ML models are baked into containers (discussed here).
- It doesn’t seem a good fit for flexibly shifting the composition of device cohorts. Adding and removing tags is not very onerous, but moving devices between applications is a more fundamental switch which involves loss of volume data, service env variables, etc. What makes a good set of devices to BETA test a particular release might shift, or may differ for particular releases. Being able to switch tags on the Device is easy and great to denote this - currently it just can’t impact release tracking.
So application separation could work, but I’m not sure it’s the best fit and am reluctant to explode out the number of applications we have in Balena cloud, especially given that we already have quite a lot of applications due to limitations in our ML containers (baked in customer models).
Is this the advised route?
Draft Releases
It’s great to see innovations in this area. I actually feel like “draft” releases is a step into this direction, but perhaps not as far as we were desiring.
They would enable us to have a “Production” cohort of devices that track the latest release automatically and are not impacted by releasing builds at lower phases of trust (development/alpha/beta type releases). The one level of separation provides this capability.
They do not go so far as to enable us to have any other cohorts that can track anything else. i.e. ALPHA devices tracking ALPHA releases, or BETA devices tracking BETA releases (draft or not).
With the ability to tag on both device and release sides, and even the staged releases examples from balena using scripting to tie tagged devices to particular releases (perhaps releases of a corresponding tag) - it does feel like the natural relationship and way to implement this. Just wondering if it’s something that fits better on the Balena cloud platform than me trying to tie the two together via some ugly API polling 
Please let me know if any other information can help understanding here, and any guidance or push in a certain direction is appreciated.
Thanks,
Louis