How we automatized delivery builds in Android (QA included)

We are artists! Let the machines do the automatic things! 💪

Human beings are lazy. I guess I’m more than average, so I try to automate everything.

I couldn’t resist The Good Good Life and, in January, I started as Jeff Android Dev. My first day in P&E (Product & Engineering) was amazing: many great people in all areas, a young and friendly environment… Everything was great until the last moment of the day, when a colleague told me: “Shall I show you how we do a build?” 🤓

😬 The beginning of chaos

The process was simple:

1. “When someone feels like doing a version (every 3 or 4 weeks), we ask by chat if someone wants to add changes to the changelog (a .txt file in the project)"
2. “When everyone has confirmed, we create a test build and we send it to QA by Fabric”
3. “When we get the OK, we manually generate the bundle and upload it to Google Play.”

🤔 What I understood

Wait, wait, wait, let me get this clear. That means:

• In my day to day life I have to constantly consult the chat in order not to lose the opportunity to put my changes.
• If QA rejects any of the Definition of Done from any of the User Stories, do we have to make any more changes before uploading it again?
• But, then we have to upload another version for QA?
• Is this agile?
• What if it’s my turn to be the loser who does the build and uploads it to Google Play? Should I say that day that I’m sick?

☝ ️First step

The whole android team agreed on the need to improve all this flow, and we got on with it.

The first step we took was to speed up the process with QA. We think that QA should receive new developments daily to allow them to review it as soon as possible:

At Jeff, our QA mates do a lot: they check that the application is applying the User Stories correctly, they try to make the application fail, they do smoke tests…

We created a gradle script, that gets all the git changes from the day before, and saves it in a file.

git log --oneline ${branch} --since=${since} --date=short --merges --pretty=tformat:%ad%x09%s

We went from Fabric to Firebase, as my mate Andrés Micó explains on his article:

Firebase App Distribution for Android

We created a daily Jenkins task that generates the build and sends it to QA through Firebase.

We are using dynamic features and that could be a problem with firebase. My mate Gabi Moreno solved it and everything is explained in his article:

Beta testing Dynamic Features with Firebase App Distribution

✌ ️Second step:

Once the delivery of User Stories is automated, it is time to automate the release and hotfix branches:

After introducing Firebase App Distribution, we created a task in Jenkins that distributes any commit from any release or hotfix branch to QA.

In this task, both unit tests and E2E tests are executed with Firebase Test Lab.

Firebase Test Lab | Test in the lab, not on your users

QA reviews specific elements of new User Stories and tries to crash the application.

👌 Third step:

Although we have solved all the integration with QA, there is still one of the most mechanical and boring steps of the process: uploading the appBundle to Google Play. We have used the gradle library:

Triple-T/gradle-play-publisher

In addition to uploading appBundles, Gradle Play Publisher allows you to configure the track, rollout... Also by adding resolutionStrategy="auto" you can automate the versionCode.

With this, each master commit (or merge in this case) launches the Jenkins task that uploads the appBundle to Google Play after passing both tests.

🚀 Never enough:

Now we can all spend more time being creative and looking for solutions that change people’s lives.

And that makes me happy. 😄

At Jeff, one of our principles is never enough 🧗, we have many ideas to optimize flows in the future.

👨‍💻 Improving flows will not only save us time in our developments. Removing mechanical and boring processes from our daily lives allows us to display our creativity, and therefore, bring more value to our users.

See you in the next post 👋

eliseo-juan - Overview

Summary:

Daily (every weekday):

1. Run UnitTests
2. Generate release notes.
3. Send staging to QA

Release & Hotfix (every commit in release/* & hotfix/* )

1. Run UnitTests
2. Run E2E Tests
3. Send dev*, staging & pro to QA

Master (every commit in master)

1. Run UnitTests
2. Run E2E Tests
3. Send pro to Google Play

*Where we develop and sometimes backend mates try out changes.