evernote release process

14
EVERNOTE: HOW WE BUILD FOR ANDROID Speaker: Reid Baker (@reidbaker)

Upload: reid-baker

Post on 29-Nov-2014

937 views

Category:

Engineering


5 download

DESCRIPTION

Big Android BBQ talk on Evernotes Release Process

TRANSCRIPT

Page 1: Evernote release process

EVERNOTE: HOW WE BUILD FOR ANDROID Speaker: Reid Baker (@reidbaker)

Page 2: Evernote release process

WHAT DO I MEAN BY “BIG”

More than a dozen android engineers

Engineers in 3 timezones

Releases go to multiple app stores, ex. Amazon, Samsung, Chromebook, etc.

Million+ reviews and more than 50 million downloads 

Android’s infamous 65k method limit

Page 3: Evernote release process

SUGGESTED TEAM BASELINE

Use source control and have some method of code review

Use a Modern build system

Verify that code compiles before it interrupts the rest of the team

Use a bug tracker so things are less likely to slip through the cracks

Have a chat room where newer members can ask questions without interrupting another teammates.

Page 4: Evernote release process

USE A MODERN BUILD SYSTEM

Choices include Gradle (recommended), Buck, and Maven

Reduces friction when adding teammates

Allows each teammate to build the same way

Encourages automation where humans might make an error

Page 5: Evernote release process

HOW WE DO IT

Make changes and test locally

Page 6: Evernote release process

HOW WE DO IT

Code reviewed

Page 7: Evernote release process

HOW WE DO IT

Jenkins Kicks off build, on successful completion

Email QA with a link to apk

Updates jira tickets found in the commit message with comment that includes build number

Kicks off UI Automation build

Kicks off chrome build to convert apk to crx

Page 8: Evernote release process

HOW WE DO IT

Build Verification tests run every build on a pair of Genymotion instances

Small set of test that run quickly

Full Set of automation tests run on 9 devices attached to the build server every night

Reports include screen shots which can be helpful to the translations team

UI tests are more fragile than unit tests

Page 9: Evernote release process
Page 10: Evernote release process
Page 11: Evernote release process

UI TESTS: LESSONS LEARNED

When working with real devices you can’t assume they are ready

We built tools that let us remove all packages, send adb commands to all devices, and restart each device

Built an app that can verify devices are ready to run tests. ex. wake the screen or verify an internet connection

Using 3rd party services like AppThwack can let you test on a broad range of devices

Knowing the commit that broke the UI speeds up the time to fix issues

Testing code in another process is not supported.

A work around is to use keyboard inputs

Page 12: Evernote release process

UI TESTS: OTHER PERKS

UI Automation has other advantages outside of testing

We can easily take screen shots of our signup flow on many types of devices in every language we support and hand those screenshots to our translations team for feedback.

We can test database migrations across a many old versions of Evernote. This process was time consuming for QA and involved a lot of waiting.

Page 13: Evernote release process

RELEASE TIMELINE

Released to 100% of users

Released to 10% of users

QA Sends sign-off email

Last change committed to release branch

(normally translations)

Release branch forked off master

Instrumentation tests pass

Unit tests andBVT pass

Play Store updated

Push Update to Beta community

Press Release/ Blog post

Partnerships Team updates other stores

Page 14: Evernote release process

QUESTIONS?

@reidbaker