Release channels are a great way for development firms or companies who develop content in-house to distribute and manage multiple app versions on multiple configurations. But oftentimes, the recipients of these app versions may want to test new versions of applications before they are pushed to all of their devices, and understandably so!
This guide will be useful to you if:
You're already using Release Channels in ManageXR
You're sharing apps with customers or other departments in your organization
Your customers or internal teams are asking what their options are for sending/receiving new versions of an application
There are a couple of methods we recommend when using release channels to share content with ManageXR. Both options are equally viable; it ultimately boils down to personal preference.
Release Channel "Push" Method
Software vendor gives two share codes to each customer: one for production (stable build) and one for testing (an upcoming new version). For the sake of this guide, we will refer to these as "Prod" and "Dev."
Customer loads the share codes and builds two configurations, one for Prod and one for Dev. If there are already designated production configurations, no need to build a separate Prod configuration. Especially if you plan to add this app to an existing configuration after testing.
When Software vendor has a new version for testing, they update their “Dev” customer release channels in ManageXR and notify customers that there is an app update ready to test.
Customer tests the dev release channel and gives the software vendor the green light to push the new version to all of the customers devices via the Prod release channel.
Software vendor updates their “Prod” customer release channels, which pushes automatically to all configurations targeting that release channel, including the customers.
💡Tip: Rolling back versions - you could also have a third release channel if you were interested in rolling back versions. Once the vendor pushes an update to a release channel, you will only have access to the current release channel version that's deployed. If willing, the vendor can create and share a third release channel called "previous version" so that you can always roll back if needed. In your configuration, you'd have access to three options: dev, prod, and previous version. Ignore the version numbers in the picture. Ideally, they would be: dev - v3, prod - v2, and previous version - v1.
The customer would rely on the vendor to ensure the previous version release channel is always one version back, so you're not rolling back two or three versions if you need to roll back.
💡 We commonly see software vendors add customer names as part of their release channels.
Pro
Less manual configuration updating. Pushes automatically to all configurations targeting the release channel. This is great for software vendors who deploy to many customers on ManageXR.
Con
The software vendor is in control of pushing new versions to all of your devices. Less quality control for the unexpected.
Release Channel "Pull" Method
Software vendor creates a release channel for every version of their app and shares the code with all of their customers every time there is an update.
Customer uploads the new version and tests the build on their dev configs.
Once the customer has deemed the app ready for production, they manually edit their configuration(s) to target the new version.
![[video-to-gif output image]](https://managexr.intercom-attachments-1.com/i/o/815116359/09b1fcfcb26c2a6d38e0ea55/ezgif-2-631a249b65.gif)
Pro
More control. Allows customers to choose when they deploy a new version instead of coordinating with software vendors.
Con
Must manually target new versions on each configuration.
Need more help?
Talk to a member of our team using the chat bubble in the bottom right of your screen, or reach out to support@managexr.com