Hello guys, I have been using Fastlane with Jenkins to build my Meteor mobile apps but I created this more than one year ago in my previous company and maybe we have a better way now.
In this solution with Jenkins I run a slave node on Mac in Cloud and use Fastlane there to build and delivery to Google Play and App Store.
I would like to know what are you using? I have seen solutions like bitrise but I’m not sure if they work well with Meteor build.
Additional nice to have, on my current company we build many apps, one per client, then would be nice if we could automatize the whole process, even the first submission to Apple. I don’t know if that is possible because in my previous company we did the first one manually.
I have successfully used the gitlab pipeline for meteor server builds and deploys.
It could be used for binary builds too, because it can have distributed runners on any platform.
After you open the xcode project, you could automate the build and deploy process using Apple Automator or something similar. Not sure if you can do this from command line, though.
We still do manual upload for the first submission. Not sure if there is any way around this to get which project to upload to.
We also have to do some manual final steps (a few clicks in app store connect) to submit the uploaded apps by fastlane either in test flight or as itunes build. Have you found any way to automate these last few steps?
For CI I use Jenkins also and have integrated that with Jira for my corporate clients teams, I built the entire testing server on one box with Android, iOS, mac and various windows installations using VMs and docker. I also used phantom headless years ago which is now gone but it’s replacement Karma is much better and works with Mocha.
In general with CI I believe test based development always wins and to clearly separate API and front-end, aiming to only have a few long tests for frontend that cover many checks and then tests for every single API method that barrage it with bad data and try to cause injections and purposefully try to break it. For front-end tests you need to cover all the obvious, is the logo still there, is login still there etc and it’s best to just group all that into one big test suite because it’s very resource intensive to fire up a instance for each time that’s why I put it all on the same server with VMs so it can just run in the rack and do each instance simultaneously, complete CI pass of hundreds of unit tests got down to under a hour this way. Out of all the Android emulator is specifically very slow to test but using a real device was not viable a we needed a server only solution. If you have devices you can use, it may work faster then emulator.
