Release transfer between fleets at the same organisation

Project help
1

Hello,
Is it possible to transfer release between fleets within the same organization?
I would like to move my release from the test environment to the production

1 Like
2

+1 for this – Asked the same question a few days ago at Transfer release between two fleets.

1 Like
4

Hello,
May I ask why you are keeping releases for the same project in 2 separate fleets? It sounds like your intention is to have a test fleet/environment and a production fleet/environment.

We have a feature in the works that would allow you to deploy releases to groups of devices, which I believe would address the issue you have raised. This feature is not finalized and we do not have an ETA for when it will be ready/available, but we are indeed working on improving the user experience for managing releases on groups of devices. Until that feature is complete and released, however, we do have some features that would be useful to you and would allow you to maintain 1 fleet containing both test and production devices (rather than 2 separate fleets). Here are the steps:

  1. Assign tags (such as beta, early-adopter, test, stable) to provisioned devices. For example, you may assign 1 device a tag that has the name workflow and the value beta and another device can be assigned a tag with the name workflow and the value stable (note that it does not matter what name or value you give the devices, they do not have to match the examples I am providing. You can name them however you prefer)
  2. From the Devices page, filter the table by tag name and/or value. As per my previous example, I would filter my table by tag name workflow and by the desired tag value, for example beta. Once you have filtered the table like so, you should only be seeing devices that have tags with the given name and value. So if I filtered by tag name workflow and tag value beta, it will only show me devices with a tag that has the name-value pair workflow: beta
  3. Now that you only see devices that are part of that workflow, click the toggle all checkbox at the upper-left-hand-corner of the table. This will select all devices that have remained as per your filters.
  4. Finally, go to the Actions dropdown and select Pin to Release and the release you would like to pin these devices to. Likewise, you can select any other batch action you would like to perform on the group of devices that are in that workflow. Now every device in the workflow will begin using the new release.

Note that any devices that are not pinned to a release will update to the latest release (or to the release the fleet is currently tracking). As a result, I would recommend pinning your fleet to the stable release. When you pin a “workflow” or “group” to another release by the aforementioned steps, they will prioritize the release you have specifically pinned them to instead of the fleet’s pinned release, so they will be able to run beta/early-adopter/test/etc. builds while every other device in the fleet continues to run their own pinned release or the fleet’s pinned release (if they do not have a pinned release themselves). Here is a doc link about release pinning (apologies for the pictures being outdated, we are continuously working on updating all of our docs): Release policy - Balena Documentation

You are also able to create draft releases. Releases that are made as drafts are not automatically deployed to devices in a fleet, even if the fleet is set to track latest and the devices do not have a pinned release. Devices and fleets must be specifically pinned to draft releases in order for the draft release to be deployed to them. Once you are satisfied with your draft release and feel it is ready to go into production, you can finalize it via the release summary page. See the following link for some info on draft releases: balena CLI Documentation - Balena Documentation . I’ll also add here that just as you are able to finalize draft releases to make them deploy to devices tracking the latest release, you are also able to invalidate any releases which you would like to revoke from devices. So if you invalidate a release that a device is pinned to or tracking, the device will be unpinned from that release and it will begin downloading the next validated release.

What all of this means is that you can push draft releases to your fleet without worry about them being deployed to production devices, filter your devices by tags intended to identify them as specific release groups (such as a test group), pin the filtered groups of devices to a specific release, and then finalize the release from the release summary page if/when you feel it is safe and ready for production. This means you can maintain just 1 fleet, instead of 1 for testing and 1 for production, and thus manage all of your related releases and devices under 1 fleet instead of 2.

I hope this was helpful! Please let me know if you have any questions or need any clarification.

7

I also have this problem, with the same use case (a production and a development fleet).

Can this workflow be completed using the command line or API? We’ve been automatically deploying images to our dev fleet on a daily basis, and would like to continue this process, while having a more manual update process just for “production”.