Built-in code quality checks for your Android Continuous Integration (CI) pipeline

Mike Wang
Mike Wang
Jul 20, 2017 · 5 min read

*Edit: I am moving my blog to medium, hopefully hosting issues won’t be a problem from now on :).

About a month back, I gave a talk at the Toronto Android Developers Meetup, in which I detailed my experience helping a company create their Android app from scratch, set up the right development process, and train their engineers on the Android platform.

Since then, I have been approached by a few companies and fellow engineers inquiring about how to improve code quality and reduce development friction. As a result, I share in this article some of the things I set up for our own engineering teams @ Hacknocraft & AppFriends, and how we ensure quality mobile app delivery.

This article touches upon tools specific to Android projects, but the concepts are obviously applicable to all software development. I also make the assumption that you already have the basics setup such as version control, and some form of code review process. If you haven’t, have a look at the excellent guide on using Git and Github.


For many developers, the thought of “This is going to be the best code ever” often turns into “Ugh… I wish we can just rewrite this whole thing from scratch” after a while. Rather than pointing the finger at the original author, this usually is an indication of process deficiencies within the engineering organization. In order to maintain code and app quality, I strongly advocate 3 guidelines within our own engineering team:

  • Maintain Good Test Coverage: having insufficient or non-existent test coverage means only 1 thing: disaster waiting to happen. For a simple one-off script, your code may work fine, but as code bases get bigger, your chances of running into bugs grow exponentially. My suggestion to engineering managers and engineers is that while skipping writing tests may save you some initial development time, it is not worth the long term negative impact, so stand your ground!
  • Fail Early: running an engineering team makes you soon realize that developer time is extremely valuable and costly. And there is no worse way to waste your developer’s time by having them review code that does not compile, or even worse, has syntax errors or does not conform to coding standards. I suggest having static code analysis tools built into the Continuous Integration (CI) pipeline so that simple issues with code quality are caught from the get go and no one wastes time at later steps if things are not ready.
  • Automation: “let engineers focus on engineering” is a common saying I try to preach all the time. If something can easily be done by machines, we should automate it. A good Continuous Deployment (CD) pipeline would save engineers valuable time to focus on actual development.

With all of the above, let’s take a look at a properly set up development process and see how these 3 things can be applied to an Android CI/CD pipeline:

Detailed CI/CD pipeline

Of all the steps listed, only the “Code Review” step should involve actual developer time, everything else is automated, handled by non-developers and triggered automatically with Github and Jenkins webhooks. I will focus on talking about “Quality Check”, if there is interest I can give more details on the rest.


Quality Check: is essentially static code analysis, which are tools that analyze code for potential issues without executing it. Setting it up is a small investment to pay for maintaining code quality. For Android development, I typically set up 4 of such to catch different categories of issues:

  • Lint
  • Checkstyle
  • Findbugs
  • PMD

Take a look at a Github repo I setup if you want to include it in your project.

Before we start, let’s take a look at a piece of working code for some code quality issues:

There are a few obvious ones and a few other you may not notice on first glance. Let’s see how each tool catches the different issues:

Lint

Lint is the default tool provided by Google / Android Studio, and it is excellent in catching a ton of Android specific issues.

if we run ./gradlew lint, we see that it complains about lines 35 and 37, where we are setting the text of the TextView with string literals instead of from resources and instead

Checkstyle

Helps developers adhere to the same coding standard

if we run ./gradlew checkstyleDebug, we see that there is a whitespace missing on line 33

Findbugs

Analyzes Java bytecode to detect issues with correctness, performance, security and bad practices

Running ./gradelw findbugsDebug, we see our mistake on line 23:

if (isDebug = true) {

where we mis-typed a boolean comparison == with a = .

PMD

Finds common programming flaws like unused variables, empty catch blocks, unnecessary object creation, and so forth.

Running ./gradlew pmdDebug, we find more annoying issues such as unused variables, or unused imports.

In less than 50 lines of code, quality checks can identify multiple issues that if unchecked, could gradually turn your entire code into a unmanageable mess. With proper setup, quality checks run automatically on every commit or every PR creation, resulting in a continuous feedback loop. Only when quality checks (and later unit tests) pass, the code reviewer would confidently start code reviewing actual logic and implementation details.


By simply adding some quality checks to your Android project, your developers will save a ton of wasted time and ensure that your code quality is up to par. Combining such tools with good unit test coverage and well planned connected tests will undoubtedly reduce your app’s bug and crash rate.

)
Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade