Android CI/CD with Zero Infrastructure

Slide 1

Slide 1 text

Push to Play End-to-End CI/CD Setup using Zero Infrastructure Arnav Gupta Co-Founder, Coding Blocks

Slide 2

Slide 2 text

IF YOU HAVEN’T REALIZED THE NEED OF CI/CD, YOU’RE NOT WORKING ON ANYTHING BIG YET

Slide 3

Slide 3 text

The ‘batteries included’ CI/CD setup • Connected well with your git workflow • Unit Tests, Integration Tests, UI Tests • Code Coverage Reporting • Test + Coverage based git push barriers • Automated release builds • Automated publication

Slide 4

Slide 4 text

WHAT IF YOU’RE POOR ? OR NON-PROFIT ? OR OPEN SOURCE ? OR JUST A MISER :D

Slide 5

Slide 5 text

Can we do it for free ?

Slide 6

Slide 6 text

Can we do it for free ? *Conditions Apply

Slide 7

Slide 7 text

Assumption 1: Open Source • Usually indie projects are open source • Non-profits / OSS orgs would want free CI/CD • If you’re a small startup, why not make your frontend OSS ? (Surely there’s no IP in frontend?) • If not OSS (you probably have the $$$ to pay) – $5/month for CI, – $5/month for code-coverage, – $5/month for static code analysis

Slide 8

Slide 8 text

Assumption 2: Trust CI host with key • Your .jks file will be encrypted • It is decrypted in a automated process • Still, theoretically it is possible for the CI host (an employee thereof) to decrypt, read and abuse it.

Slide 9

Slide 9 text

What all do we get ? • Build checks ? • Unit tests ? • Integration tests ? • Coverage reports ? • Code style checks ? • Code complexity ? • Automated code review? • Deploy to Play Store ? ü ü ü ü ü ü ü ü

Slide 10

Slide 10 text

A HYPOTHETEICAL SCENARIO You wrote (a == b) instead of (a != b)

Slide 11

Slide 11 text

What this setup provides ? a) (a==b) instead of (a!=b) won’t happen if the tests are in place, but still. . . b) Open Github on a browser (even on your mobile) c) Edit within Github d) Within few hours, corrected App published to Play Store.

Slide 12

Slide 12 text

No content

Slide 13

Slide 13 text

No content

Slide 14

Slide 14 text

SERVICES WE ARE USING

Slide 15

Slide 15 text

Builds, Unit Tests, Integration Tests • Travis CI • Only Github repos • Has Mac OS servers (Yay! iOS too) • Circle CI • Faster, if using v2.0 config (warn: verbose to setup) • Supports Butbucket and Gitlab as well

Slide 16

Slide 16 text

Builds, Unit Tests, Integration Tests • Gitlab Builds • Free (even closed source) • Slow, limited slots, not very reliable • Bitbucket Builds • 500 min free with base back • Cost approx $1~2 per developer (unlimited repos) • Appveyor • Allows building on Windows • Can be used for Electron app builds for Windows

Slide 17

Slide 17 text

Code Coverage Reports • Codecov • Zero-config setup with Travis/Circle CI • Only Github • Cool Chrome/Firefox extension to view coverage inside Github • Wider support of coverage formats (lcov, jacoco and more) • Coveralls • Faster & snappier web ui • Not locked to Github

Slide 18

Slide 18 text

Static Code Analysis • CodeClimate • Supports way too many things • Requires verbose config file • Also supports coverage report • Some reports are not generated (no way to force re- generate)

Slide 19

Slide 19 text

Static Code Analysis • Codacy • Works well with Java code • Fast and clean web UI • Ambiguos marking scheme • CodeBeat • Opt-in configs, automatically reads code too • Best marking scheme (personal experience) • Complexity analysis is top notch

Slide 20

Slide 20 text

Deployments • Library • Jitpack (publish directly from Github) • Skip the Maven/Jcenter publishing headache • App (Play Store) – Fastlane • A tool/script, not a service • Needs to be configured and run from Travis/Circle

Slide 21

Slide 21 text

git push build Static analysis passed notify github notify github run tests passed no yes no Deploy to Play Store yes • Github • Travis/CricleCI • Code Analysis Service • Google Play API Process Overview

Slide 22

Slide 22 text

SETTING THINGS UP

Slide 23

Slide 23 text

What kind of tests ? • Unit Tests • Runs on local JVM • Cannot use Android SDK stuff (com.android.** ) • Integration Tests • Runs on a device/emulator/cloud device farm • PRETTY DAMN slow (many tests = builds in hours) • Robolectric (the middle ground) • Mockito on steroids, done correctly, for Android • Run integration tests on local JVM

Slide 24

Slide 24 text

Unit Tests • Business logic • Does not depend on Android SDK • Try to get 100% coverage of non Android component code here Robolectric Tests • Depends on Android SDK, but not UI • SQLite, HTTPClient, JSON libcrypto all work OK • Cover everything that’s not UI or requires lifecycle Integration Tests • UI tests and lifecycle tests • Tests are flaky, so do not depend critically • Use Espresso for UI tests

Slide 25

Slide 25 text

Merging coverage reports • Android Studio shows coverage in-IDE for unit tests. Not for integration tests • gradle generates jacoco xml report for integration tests, not unit tests. • UGGGGGHHHHHHHHHHH!!!!!! • Let’s merge them

Slide 26

Slide 26 text

Merging coverage reports

Slide 27

Slide 27 text

Merging coverage reports

Slide 28

Slide 28 text

Deploying to Play Store (even iTunes) • Use Fastlane “Supply” module • Lookup reference config on http://github.com/tdillion/android

Slide 29

Slide 29 text

Create keystore and encrypt on Travis keytool -genkey -v -keystore /PATH_TO_/MY.jks \ -alias MY_KEYSTORE_ALIAS \ -keyalg RSA -keysize 2048 -validity 10000 travis encrypt-file /PATH_TO_/MY.jks --add

Slide 30

Slide 30 text

Build signed apps from Travis script: - "./gradlew assembleRelease" - jarsigner -verbose -sigalg SHA1withRSA \ -storepass $storepass -keypass $keypass \ -digestalg SHA1 \ -keystore MY.jks PATH_TO_/MY.apk MY_KEYSTORE_ALIAS - zipalign -v 4 PATH_TO_/MY.apk PATH_TO_/MY_RELEASE.apk

Slide 31

Slide 31 text

Enable Play Store Publishing API

Slide 32

Slide 32 text

Publish using Fastlane Supply supply init -j PATH_TO_GOOGLE_API.json -p MY.PACKAGE.NAME supply run -j PATH_TO_/FOO.json \ -p MY.PACKAGE.NAME \ -b PATH_TO_/MY_RELEASE.apk

Slide 33

Slide 33 text

CASE STUDIES

Slide 34

Slide 34 text

No content

Slide 35

Slide 35 text

No content

Slide 36

Slide 36 text

No content

Slide 37

Slide 37 text

Easy to evaluate PRs at a glance

Slide 38

Slide 38 text

Detailed report per PR

Slide 39

Slide 39 text

Code Quality Report, Codacy

Slide 40

Slide 40 text

Track quality over time

Slide 41

Slide 41 text

Detailed code analysis

Slide 42

Slide 42 text

No content

Slide 43

Slide 43 text

Bonus: Previews • Using Appetize.io API • Publish to Appetize on every RC build • Preview App over web (easy to show project managers without having them build/install)

Slide 44

Slide 44 text

No content

Slide 45

Slide 45 text

Bonus: Automated Github Releases • Supported by both Travis and Circle (Travis easier to configure) • Release on every tag • Specify particular branches • Specify release artifacts to upload