Yes, there is! Check the scripts in the staged releases repo:
Of course, as a sample project, you don’t have to use those scripts as they are (though you can): ultimately they build on the balena API, so if you wish, you can re-write parts of it in your chose programming language, to integrate with your deployment process.
In terms of having a staging and production environment, is it common practice to add multiple remotes to the same codebase, for example
git remote add Balena-staging ... and
git remote add Balena-production , each of which represents a different Balena cloud app?
Two parts to this one:
- Using different balena applications for staging and production: this sounds like a reasonable and logical way of going about it and I should think it is common practice, though I’ll let anyone else chip in with further advice.
- Using git different git remotes: this is probably common if you are using the “git push” deployment method, but I believe that most “advanced” users use the balena CLI for all the additional features it offers in relation to deployments: private docker registries, build secrets, local image builds, build on dedicated hardware, mix of cloud and on-premises and so on. All achieved with the different commands:
balena push deviceIp
balena push appName
balena deploy --build
balena build -h hostaname -p port
Check these docs for a bit more info on the deployment options: