Let’s cover how to set our project up so that it will automatically publish to the Google Play alpha testing channel.
We’ve covered why to go with a Continuous Delivery pipeline, how to set up the build in Travis CI, and how to add unit tests to increase your confidence in the application, but we haven’t talked about the Delivery part of Continuous Delivery.
Why Google Play Alpha?
The reason we are deploying to Google Play and not some other beta testing service, is that Google Play is going to be the app’s eventual home anyway, so why not get there as soon as possible?
Doing this will expose issues associated with Google Play distribution more quickly, such as:
- The 50MB APK size limit
- Handling of expansion packs and their updates
- Device and screen size filtering
- Distributions of APK’s per architecture, size, API version, etc.
- On and on…
…and faster feedback is always better.
Going directly to Play also gives us the ability to:
- Promote the APK to production with the push of a button
- Let users opt-in for public beta testing without requiring installation of additional apps or tools
The simplest way I’ve found to integrate with Google Play APK publishing is by pulling the Triple-T Gradle Play Publisher plugin into your Gradle build system. The setup instructions in the project’s readme are simple and easy to follow so I won’t cover them here.
Other options exist, like using a Jenkins plugin if you’re running Jenkins, but the good thing about going the Gradle route is that it’s independent of the CI environment. Whether you use an in-house Jenkins server, a hosted Travis-CI server or some other CI environment that doesn’t exist yet, keeping your build tasks in Gradle makes your project easily portable to other build environments as your organization’s needs change.
In general, it’s best if you limit your dependence on outside tools and environments as much as possible. A good test of this is if you can clone the project fresh from Git and run the full build-and-deploy process end-to-end with a single command line command on your local machine. (You’d need Java, the Android SDK and your secret keys on hand of course.)
In addition to the easy publishing of the APK, one thing I like about this plugin is that you can update and track the Play Store information inside your project and therefore in source control. This lets you maintain release notes and other store info as a normal part of your development workflow.
For example, as part of the development of a story, your team’s process could be to add a line item to the whatsnew file for each feature or fix. That way, when the work gets merged with the master branch, the release notes will continue to be appended to and automatically publish with the APK when it’s deployed to the Google Play Store. This can also be done per language if multiple languages are supported.
If you want more control, or have a different audience between alpha, beta or production, you can create a separate release notes file for each channel by specifying a whatsnew-alpha file. That way your testers or business owners can see more details, and the end users can see some marketing-sanitized version of it.
Screenshots And Other Store Information
Another thing you can incorporate into the overall workflow is updating the screenshots and description for the Play Store page. If work on a story includes a redesign of one or more screens, your developers can check in new screenshots along with the work that changed them. Or if features are added or changed, the store description can be updated to reflect the changes. This way your Play Store presence can stay up to date in real-time with the actual features as they are being developed.
Now, every time we merge a pull request into master it not only contains the new feature code but has been verified by automated tests, peer reviewed, contains updated release notes and screenshots, and has any other Play store info that’s needed. So, there’s no reason that this build can’t be automatically deployed to (at least) your first level of testers and business users, automatically.
What if you want more control than this? Well, that’s ok. Just because it’s “deliverable” doesn’t mean you have to deliver it on every merge. You may have a scenario that requires some gating of the delivery for one reason or another. You may want a PM or QA person to do a final review, revise release notes, communicate to the product owner or customer, etc. If so, it’s easy to set things up so that you instead publish to Google Play on demand. One good way to do this is publishing the APK when a git tag is created.
We’ve done something similar at stable|kernel by creating a bash script that makes this determination. Basically, if there’s a TRAVIS_TAG environment variable, assemble it and deploy it, otherwise just run the unit tests. It could look something like this:
if [ $TRAVIS_TAG ]; then echo "Assembling and publishing release" ./gradlew assembleAcmeRelease publishApkAcmeRelease else echo "Assembling and testing Debug" ./gradlew assembleAcmeDebugUnitTest testAcmeDebug --tests="com.acme.model.*" fi
Now we’re just a simple git command away from kicking off the deployment when ready. The important thing is that all points in your deployment pipeline are either fully automated or just a “push of a button” away.
Livin’ The Continuous Delivery Lifestyle
At this point, you have a streamlined way to get a build into the Google Play Store. And since this build has a high level of confidence being “shippable,” this means that with minimal decision making or friction, builds can be promoted to beta or even production with the push of a button. It’s up to the product owner at that point, and they have the power to make it happen when they want. Meanwhile, the developers can move on to the next set of features in backlog without having to be bothered with “putting a release together.”