Setting up TeamCity for Android uploads to Fabric Beta (Crashlytics)

Our team recently switched to a Gitflow style Git workflow. I won’t bore you with tales of our previous “process”, sufficed to say we’re trying to have a better workflow for getting features into our product. Getting the updated feature build into the hands of our QA department as quickly as possible has been key to our improvements. Fabric Beta(formerly Crashlytics) enables us to publish and manage those builds easily.

Our new workflow requires developers to make a pull request for a new feature, which is represented by a YouTrack issue. This pull request is reviewed by the other developers and the automatic build is run and tested on TeamCity with the results attached to the pull request on GitHub. At the same time, the build is uploaded to Crashlytics(Fabric Beta) and our Android QA team receives a notification of the new build. From there, they can test and progress the YouTrack issue to the proper state. If the issue is resolved, tests pass, and developers approve the change, the new feature pull request is accepted into the develop branch. From there we do a “release” to the master branch and the Play store when ready.

Here’s how we set it up:

Within your TeamCity Build configuration VCS settings, you’re going to want to set up a branch specification to grab all of your pull requests. We setup our default branch to point to develop, and then used the branch specification below:

+:refs/pull/(*)/head

This tells TeamCity to build every pull request that comes in and uses the value inside the parentheses as the name of the branch. In this case, that’s the same as the pull request id.

Now, setup or copy your Android build steps to get a working build. We use the following Gradle tasks in order to build and upload to Fabric/Crashlytics:

:app:clean :app:assembleProdDebug :app:crashlyticsUploadDistributionProdDebug

In order to differentiate builds on Fabric, we take the extra step of appending the pull request id into the version name(I’d much prefer to use the YouTrack issue id, but I haven’t figure that one out yet…) For this, we add a build step ahead of the Gradle Tasks. The step we use is a Command Line runner with a custom script. Our script is as follows:

export PULLREQUEST=`echo %teamcity.build.vcs.branch.Android_GitPullRequests% | sed “s/refs\/pull\/\(.*\)\/head/\1/” | sed “s/refs\/heads\/develop/develop/”`
echo Found pull request number $PULLREQUEST
cat app/build.gradle |sed “s/versionName ‘\(.*\)’/versionName \’\1-”$PULLREQUEST”\’/g” > “build.updated”
mv build.updated “app/build.gradle”

The script uses sed to pull out the pull request id(or develop for the default branch)from a teamcity environment variable, it then uses sed again to append the pull request id to the versionName within the build.gradle file. Our dependence on sed means this doesn’t work on a Windows build agent without some changes, but I think you can accomplish similar with powershell.

We then create a new build configuration and setup the GitHub change status Feature. You can do this by adding a new Feature to the configuration and selecting the “Report change status to GitHub” feature. Use the URL below for standard GitHub accounts.

At this point you should have continuous deployment of your Android apps to your QA department. Maybe one day we’ll get brave enough to do the same thing to production with our master branch…