Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Android CI/CD with Zero Infrastructure

37fbf83b7d45711e41e774e29fed710e?s=47 Arnav Gupta
October 05, 2017

Android CI/CD with Zero Infrastructure

Using Travis, CircleCI, CodeCov, Coveralls, Codeclimate, Codacy, Codebeat to create a zero config, zero maintenance, zero infra continuous integration and deployment pipeline.

37fbf83b7d45711e41e774e29fed710e?s=128

Arnav Gupta

October 05, 2017
Tweet

Transcript

  1. Push to Play End-to-End CI/CD Setup using Zero Infrastructure Arnav

    Gupta Co-Founder, Coding Blocks
  2. IF YOU HAVEN’T REALIZED THE NEED OF CI/CD, YOU’RE NOT

    WORKING ON ANYTHING BIG YET
  3. 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
  4. WHAT IF YOU’RE POOR ? OR NON-PROFIT ? OR OPEN

    SOURCE ? OR JUST A MISER :D
  5. Can we do it for free ?

  6. Can we do it for free ? *Conditions Apply

  7. 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
  8. 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.
  9. 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 ? ü ü ü ü ü ü ü ü
  10. A HYPOTHETEICAL SCENARIO You wrote (a == b) instead of

    (a != b)
  11. 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.
  12. None
  13. None
  14. SERVICES WE ARE USING

  15. 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
  16. 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
  17. 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
  18. 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)
  19. 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
  20. 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
  21. 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
  22. SETTING THINGS UP

  23. 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
  24. 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
  25. 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
  26. Merging coverage reports

  27. Merging coverage reports

  28. Deploying to Play Store (even iTunes) • Use Fastlane “Supply”

    module • Lookup reference config on http://github.com/tdillion/android
  29. 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
  30. 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
  31. Enable Play Store Publishing API

  32. 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
  33. CASE STUDIES

  34. None
  35. None
  36. None
  37. Easy to evaluate PRs at a glance

  38. Detailed report per PR

  39. Code Quality Report, Codacy

  40. Track quality over time

  41. Detailed code analysis

  42. None
  43. 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)
  44. None
  45. 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
  46. Bonus: Automated Github Releases

  47. Bonus: Automated Github Releases

  48. Bonus: Automated Github Releases

  49. None
  50. Bonus: Complexity reports on PR comments

  51. Bonus: Coverage delta comments

  52. Bonus: Coverage delta comments

  53. Codebeat: Quick Wins

  54. HOW ABOUT DESKTOP APPS ?

  55. None
  56. Automated signed builds for Win + Mac

  57. Automated signed builds for Win + Mac

  58. YOU DESIGN THE PRODUCT, LET THE MACHINES BUILD IT

  59. YOU WRITE THE CODE, LET THE MACHINES PACKAGE IT

  60. YOU CONJURE NEW FEATURES, LET MACHINES CHECK OTHERS’ BUGS

  61. @championswimmer a@cb.lk