@dfunckt that is correct. We have a number of test vehicles, and we can deploy test builds to one or many of them at any time for development. Those test builds never get pushed directly to customers. We also have a number of bench devices of course, but many of those are operated remotely much of the time.
Local mode actually came up on another thread (Release builds getting "cancelled" unexpectedly. - #18 by adamshapiro0) and unfortunately it doesn’t work for our use case. Copying from that post:
- Devices must be available on your local network
- Our devices are often deployed in moving vehicles, and the developer testing against it may not be in the vehicle
- We often test a single build on multiple devices and we wouldn’t be able to simply pin the devices to an existing dev build. Unless everyone is very careful, this can potentially be error prone or lead to inconsistencies if someone accidentally builds differently, etc., which could be difficult to recognize and track down
- Environment variables from the cloud do not apply
- We use the environment variables for a number of things, including turning on/off some development settings on the fly. Having to manually set them in the docker compose file to be in sync with the settings in the cloud every time we do a quick development test isn’t really feasible and is error prone
- To deploy on multiple devices the developer would then have to set the compose file for each device by hand and make sure they got all the settings right, which takes time and is easy to get wrong, and then run separate builds for each of those devices
Our preference would definitely be to use the Balena cloud build servers for development builds. Worth mentioning that the Balena documentation specifically recommends using the remote build servers for development:
balena push is the recommended method for deployment and development on the balenaCloud platform.
Ideally, we would love to have an option for or something balena push to simply indicate to the build pipeline how it should generate deltas. Not sure what it would take to implement, but my preference would be to generate one delta since the “last build generated by this user”. That way, someone iterating quickly on a group of devices would generate only the delta they needed, and the delta sizes printed to the console at the end of the build would reflect the actual size of the delta to their devices instead of the size of a hypothetical push to customer devices, which will never occur. That would certainly be my preference.
Alternatively, honestly an option to simple disable automatic delta generation would work as well. Customer releases don’t happen nearly as often as development builds so we’d rather not waste the time (and Balena’s cloud storage for the deltas that will never be used). The reality is that first customer to the gate to download a new release probably won’t even notice if they wait slightly longer than usual or than other customers, and if that really became a problem we could always deploy the release to our test vehicles immediately to prevent that. In practice, we always deploy official releases to our vehicles so that would probably be a non-issue.