Devices Cohort Pinned to Automatically Track Release Tag

I understand within an application you can set a device to track the latest release for rolling updates.
I also understand that you can pin a device to a specific release.
Can I pin a device to track the latest release that has a specific tag?

I’ve seen advocation of using tags on devices to update them to be pinned against a specific release.
The staged-releases repo demonstrates use of this api here, and is very helpful:

I’ve also seen on these forums endorsement of using tags on devices and corresponding tags on releases to tie these together:

However, this is not an automatic update like tracking the latest release. I was wondering if features have moved on since, or if this was on the roadmap? (although I admit I didn’t spot it):

Ultimately, we will likely have different release groups such as ‘Alpha’, ‘Beta’ concepts for cohorts of devices and would want to promote releases through testing phases. We also might want to have development releases that are not automatically pushed to the production devices running a particular application. These are all ultimately release versions of the same application.
Without this feature, and without events/webhooks notifying of a new release, I would need to engineer something to poll the Balena API and constantly try to co-ordinate updates of device cohorts to keep them tracking the correct tagged release.
Just want to check if this is the best way right now to achieve this goal, as it seems to have a lot in common with features already available?



Hi @louisburton,

What you shared are the latest features related to release pinning. We are not as far as I’m aware working on functionality that would allow you to have different release groups however that doesn’t mean that we would not consider it.

Regarding development releases, we are currently implementing proper release versioning into balenaCloud which as a byproduct will include the concept of “draft” releases. Draft releases will not be tracked for latest so won’t get pushed into any devices set to track latest.

Going back to the multiple release groups, is there any reason creating multiple applications would not suffice for your use case? I can raise this for internal product discussion but I want to better understand the use case first.

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:

  1. 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).
  2. 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 :see_no_evil:

Please let me know if any other information can help understanding here, and any guidance or push in a certain direction is appreciated.