Build your Android app with Bitbucket Pipeline and HockeyApp

Configuring a continuous integration can be tricky for mobile apps. Let’s see how quick it is to build an Android app with Bitbucket Pipeline and deliver it with Hockey app.

If you missed it, Bitbucket Pipeline is a continuous integration service that Atlassian geniously integrate in their git solution Bitbucket last year. It’s based on Docker container technology and require only a YAML file to start using it.

Bitbucket Pipeline

To start using Bitbucket Pipeline, you simply need to go to your repository, and under the Pipeline menu enable it.
It will automatically create a YAML file to start with under your master branch.

Based on Docker, you’ll need a Docker image to use to build your app. It has to include your Android build environment to be able to compile it. To simplify it, Uber dev team created one for this purpose that you can use here. If you are familiar with Docker, I would recommend to create you own image instead, you might not need everything that Uber included in their image. It would create a lighter image to use and improve how hast your pipeline takes time.

First, I specify the image that is going to be used to build the app. Then by default, for any branches, it will execute commands. Here I build a debug APK using Gradle wrapper. Our continuous integration is ready!

What if I want to do specific steps for a branch?

Good question. Bitbucket Pipeline documentation includes many commands to customize your build, including one to specify branches.

On my side, I also like having separated scripts that can be reused, so I created a build.sh file in my repo.
Be sure that your script can be executed by giving the right permissions.

Well, another good question. Let’s say that by default, you want to be sure the app can still be build and run the test. You can do that by customizing your build.sh for that by updating Gradle command lines.

But then, once built and tested, for a specific branch, you can actually deploy it somewhere. That’s what we’re going to do with HockeyApp.

Hockey App

HockeyApp is platform that let you distribute your iOS, Android, OS X and Windows apps to your testers. It’s a really nice solution for beta testing in a continuous delivery process. It also includes extra services like crash reporting, analytics and user feedback.

To use it with Bitbucket Pipeline, we need API access. Under your account settings > API Tokens, select your app and upload only rights to create your first API token. I would recommend you name it after Bitbucket Pipeline to make it clear for you (or your team).

Now let’s create a new script in your repository to upload an APK to HockeyApp. Here is my deploy-hockey-dev.sh

Here is the documentation For more info about Hockey App api. Here we allow to download the apk with status=2 but won’t notigy user with notify=0. The ipa needs to point to the built apk previously. Finally, we’ll need the tocken previously created but also the app id that you can find on the main page on Hockey App.

To avoid having your private token and app id in clear, let’s add them as Bitbucket Pipeline environment variables.
On Bitbucket, under Settings > Pipeline > Environment variables, add each of your key there. Set as secure for your token to be sure it won’t be displayed in the shell.

Now, develop branch will be build and upload as a debug apk into Hockey app for every pull request merged.

To go further

What if I want a release APK?

To be able to sign a release APK, you need a Android keystore and a passphrase. It’s not recommend to put the private key in your repository, specially for a public repo. However, if you so do, you can add passphrase as a variable environment to limit the risk.

Finally, this post gives you a quick introduction to what can be possible with Bitbucket Pipeline.
Some extra steps might be required depending of the deployment environment, here the Docker image used, or you Android project itself, including Gradle wrapper property for instance.

If you care about user experience, error handling is a big part you have to cover. We can design how an mobile app looks like when it works, but what happen when something goes wrong. Should we display an alert to the user? Can the error stay silent? And mostly how to implement it the best way with your current design pattern? Let’s see our options while following MVVM pattern.

The best way to learn and become more creative as a developer is to focus on a side project. A really good friend coming back from Japan came to me with an idea when I needed that side project. This is how we created Japan Direct, from the idea to the App Store in almost no time.

For the last couple weeks, I tried to step back on my development to analyse what is time consuming in mobile development. I realised that most of new views are based on same approach, reimplementing an similar structure around a UICollectionView or UITableView.

What if I can have a more generic approach where I can focus only on what matters, the user experience. That’s what I tried to explore in this article.

Last couple weeks, I have traveled with only my iPhone with me and I realised how many apps I daily used still relying on their websites. Even with the right iOS app installed, I had to browse on Safari app to get specific details. That is why it’s so important to support universal links in iOS. Let me show you how.

Firebase is a set of tools introduced by Google to build better mobile apps. I worked with this many times and even if it’s straight forward to integrate, here are couple advices of implementation to make the most of it.

I recently followed a growth marketing course, introducing mindset and methodology to make a company grow. I learnt a lot from it and since, I try to apply this knowledge on a daily basis. After more reflection on it, a lot of ideas looked very similar to software development job, this is the part I would like to share.

If you have an iOS app, you might have integrated external libraries and tools to help you getting your product ready faster. However your iOS architecture and swift code shouldn’t depend on those libraries.

The best part of continuous integration is the ability to automatically run tests and build apps, ready to be deployed. However, automatic build doesn’t mean smart or optimised build. Here are some tips I collected along the way to speed up delivery process.