The making of eero’s Android app

The making of eero’s Android app

How we catch bugs early and improve team communication

Making an easy-to-use product that improves people’s lives is the core of our brand at eero. That sort of mindset also applies to how we develop software, including the process for how we write, test, and distribute code for our Android app. We’ve refined this build process from one that required an assortment of manual tasks and was prone to human error to one that improves team communication and allows us to develop more quickly.

Requirements for our build process

When thinking about improvements, our driving goals were to automate tedious, error-prone tasks and improve communication. We also wanted to catch code issues as early as possible without creating additional developer work. To make our lives easier, this build process needed to be:

  • Stable — The build process always works
  • Comprehensive — New code is tested; style and code analysis is run before integrating changes
  • Communicative — Repetitive work that facilitates team communication is automated

Steps for an awesome build process

Our focus is on how code is integrated and shared within the team. Without interfering with workflow preferences, we try to give developers non-intrusive warnings about potential issues.

The most important parts of our build process can be divided into several steps:

  1. Run checks in local environment
  2. Run tests on Pull Requests
  3. Run static code analysis on Pull Requests
  4. Update ticket status with build number after successful build
  5. Distribute builds with release notes to team members
The checks and services used as our code goes on its journey to production. The most important parts start once a pull request is opened.

1) Run checks in local environment

Whenever we save code, a set of formatting and styling rules are applied so the code looks more consistent and we have fewer issues when integrating changes.

In Android Studio, our environment for developing eero’s Android app, potential bugs and code problems are highlighted to make the developer aware of them. This gives the developer early feedback without being intrusive or prescriptive about how to fix the problem.

2) Run tests on Pull Requests

Tests aren’t valuable unless they’re being run regularly and providing feedback. Including tests in our process also encourages a culture of writing tests and testable code.

More testing should be done automatically. It’s important to note that by “automatically” we mean that the test results are interpreted automatically as well. -Andrew Hunt, The Pragmatic Programmer

In addition to simply running tests for all pull requests, we require that all tests pass before a pull request can be merged. To enforce this requirement, we enabled protected branches and status checks on Github, thereby requiring that all integrated code is tested and has passed code review. This step is great to make sure the build isn’t broken and code changes haven’t regressed a unit test.

3) Run code analysis on Pull Requests

On a small team, asking for a pull request review is like asking a friend to proofread your blog post. That friend is happy to give feedback, but she might not want to search for all the spelling and grammar errors, too. To maintain friendships, and take some of the tedium and pressure out of code reviews, we run code analysis on all pull requests, which is like running spelling and grammar checks on a text document.

Example GitHub PR feedback from SonarQube

4) Update ticket status with build number after successful build

Updating tickets can be a tedious, error-prone part of the development cycle. To improve this process, we automatically progress tickets to their “Ready for QA” state and include a comment with the build number where they are fixed.

The JIRA Plugin for Jenkins provides exactly this functionality. This plugin improves everyone’s life by keeping tickets up-to-date and tagging them with build fix numbers.

5) Distribute builds with release notes to team members

At eero, we use Fabric’s Beta service to share test builds with the team. One nice feature of the Beta service is that it allows uploading release notes with new builds.

We take advantage of this feature so that whenever emails are sent from Fabric Beta, a section called “Release Notes,” which outlines the changes since the last build, is included.

Release notes included in an email from Fabric Beta

What’s next?

We have a lot of ideas on how to continue to improve this process, but we’ll only include them if they hit our bar for quality and ease-of-use. Some things on our mind are:

  • Automatically optimizing images to reduce app size
  • Running an automated suite of tests on devices for even better test coverage
  • Tracking performance metrics, including frame rate and boot time

Is it all worth it?

We think so. Automation has improved team communication, saved time, and allowed us to write better code. And, at the end of the day, this allows us to develop features more quickly and maintain the high quality bar that our customers expect. Want to help us continue to improve this process? eero is hiring.


28 thoughts

  1. After going over a few of the blog posts on your website, I really appreciate your technique of blogging. I bookmarked it to my bookmark site list and will be checking back soon. Take a look at my website as well and let me know what you think.

  2. Very great post. I just stumbled upon your weblog and wished to say that I’ve really loved surfing around your weblog posts. In any case I will be subscribing on your feed and I am hoping you write once more soon!

  3. Every weekend i used to pay a quick visit this web site, because i wish for enjoyment, for the reason that this this website conations truly nice funny information too.

  4. Ahaa, its pleasant conversation concerning this paragraph at this place at this weblog, I have read all that, so at this time me also commenting at this place.

  5. Hello There. I found your blog using msn. This is a very well written article. I will make sure to bookmark it and come back to read more of your useful info. Thanks for the post. I will definitely comeback.

  6. fantastic post, very informative. I wonder why the opposite specialists of this sector do not notice this. You should continue your writing. I’m sure, you’ve a great readers’ base already!

Leave a Reply

Your email address will not be published.