Automating Meteor/Cordova App Signing
Manual deployments create risk of human error, and discourage frequent releases. Therefore automating app deployment is a valuable addition to a team.
What do I need to learn about?
bash, Jenkins build agents, app signing process.
Assuming we have a Minimum Viable CI setup with docker. Were going to add a few steps after the build to prepare to publish our mobile apps. You should already be capable of manually signing and building .apk and .ipa files.
Automating android is a breeze and rarely has issues because the apk is already build and only needs to be signed and zipped.
This is where it can get fiddly. My advice is to git init your ios build folder and commit the initial state. This will help you revert if you click the wrong thing in xcode, and review changes.
Step 1: If you open your .xcodeproj you’ll notice a Manage Schemes dialog in the toolbar. We are going to need to set the app Scheme to shared. This will generate an .xcshared xml file. Commit this along with your meteor project repo. At build time were going to copy this into place.
Step 2: Meteor as of 184.108.40.206 cannot set different bundle ids for android and iOS. So if like us you want to use different bundle ids you will need to find an replace all instances of the android bundle id. I’m using npm replace tool which was installed globally on the build agent, it supports regex and reads well in a bash script.
Step 3: Create the .xcarchive file and export it to .ipa. This is where most of the problems are going to occur. It’s possible there may be other configuration options you project may need. In our case adding local cordova plugins often results in very strange paths which may need to be fixed. Whatever your last minute configuration change you can use git to see what has change in the xcode project and make that same change with bash.
A good CI setup should support traceability, and therefore increment the build number to help identify which build the app came from. In the following script we are grabbing the git hash of the latest commit the build date and the Jenkins build number to provide a good context for debugging.
Its also possible to use ‘cordova-plugin-appversion’ to grab this and make it available inside the app for the user to see.
So by now we should have our mobile apps ready to deploy with version numbers which can be displayed in the app and in the logs. We are publishing these to fir.im using the fir-cli. Which is free, supports rollbacks and version numbers but can be a little unstable at times.
Next time, debugging production cordova apps by logging as much as possible, unhandled exceptions on client and server and analysing logs effectively.