Our Continuous Delivery Journey for android apps :: with Jenkins

We, mobile developers, at Jombay started using continuous delivery of our apps quite some time ago, and we started out with Jenkins. It didn’t prove out to be as smooth as expected but we did end with a better solution.

Jenkins is a great tool. The number of plugins it provides to integrate in task pipelines and the number of combinations of plugins that help you achieve your task is amazing but when it came to simply automating build of our Andriod app from a git repo, it was just meh.

It won’t make sense to write the whole setup here, since I followed an already existing solution on internet and here it is for you: Setting up Android Package Kit [.apk] generator using Jenkins job [Gradle|Git] by PANKAJ JANGIR

Our task was to generate app builds from git repo, whenever our QA team needs it with a simple hit of URL, and notify them about the fresh build. While configuring our job for the build, following things had to be taken care of:

1. Android SDK Installation: (Manual) If you manually install the Android SDK on your server machine at the provided ANDROID_HOME environment variable path, then it’s gonna work fine given the remaining setup goes fine. (Automatic)Else, you can leave the SDK installation to gradle while build is being created. It automatically installs the required SDK components at ANDROID_HOME environment variable path. This also follows the condition that you have exported the licenses in the SDK directory, as mentioned here.
2. Android .apk signing: If you wish to generate a signed apk, then you have to install a separate Android Signing plugin for that. There are other ways to sign apks in Jeknins but they just disclose your keystore password in one way or another. This plugin doesn’t support the usual .jks format of the keystore. You have to convert your keystore in PKCS12 format, store it in jenkins credentials storage system and then use it.

$ keytool -importkeystore -srckeystore pkey.jks -destkeystore pkey.p12 -srcstoretype JKS -deststoretype PKCS12

3. Notifying our QA team: I started out with using a mail plugin to notify our QA team but we ended up finding a better solution, HockeyApp. Initially, while using a mail plugin to find the correct .apk from build artifacts and send it as an attachment became a pain. HockeyApp is a great solution for uploading your beta builds, sharing them within your team, automating mails when new build is available. And with the power of Jenkins plugin, I integrated the HockeyApp plugin in my Jenkins Job and uploaded the .apk on HockeyApp, which in turn automated the mail to my Dev & QA team.

After taking care of all these things, we started receiving ‘Unable to start daemon process’ exception sometimes while creating builds. Our build success rate was very low. This turned out to be a low RAM issue of our server machine.

All of this was painful in terms of time and efforts but one thing that made it all worth was that we landed on App Center(Hockey will soon be migrated to App Center). Our experience with App Center has been amazing so far. It took only 10 minutes to setup the whole Continuous Delivery of our apps. And just like that we started rolling with it.

How easily we did it?! To be continued… here.