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

Continuous Integration: Catch Bugs and Improve Team Communication

Continuous Integration: Catch Bugs and Improve Team Communication

GitHub project for demo: https://github.com/jordanjoz1/andevcon-demo

A good build process makes everyone’s lives easier. Running tests and static code analysis gives developers confidence and peace of mind. Product managers and QA benefit from automatically shared builds that clearly indicate changes. In this session, we will expand on the concept of a CI process and talk about some ways to automate everyday tasks, including pull request feedback, testing, and distribution.

We will discuss several opportunities for automated improvement. First, sharing style formatting to improve readability and reduce merge conflicts. Second, showing results of automated testing and static code analysis in pull requests to improve code quality and reduce bugs. Last, how to automatically distribute builds and update tickets to improve intra-team communication. Whether you choose some of these tools or all of them, they will make your life easier. Our focus will be on a comprehensive solution using Jenkins, SonarQube, Fabric, JIRA and Github, but we will also compare alternative services.

Want to get started with these processes now? You will have details for installation instructions, plugins, and configurations. By the end of this talk, you will understand how to setup and use all these services so that they do the heavy lifting in your development process.

15019b1cef68cc081d0ca67a32012c86?s=128

Jordan Jozwiak

December 01, 2016
Tweet

Transcript

  1. Continuous Integration: Catch Bugs and Improve Team Communication Jordan Jozwiak,

    eero
  2. First, let’s agree on some values

  3. It’s better to automate processes than do them manually

  4. It’s better to have consistent code style than mix multiple

    styles
  5. It’s better to catch bugs during development than during the

    QA process
  6. It’s better to automate routine communication than rely on individuals

  7. Is this really Continuous Integration? What can I do? When

    can I do these things? How can I do these things? Guiding Questions
  8. This isn’t really Continuous Integration

  9. This isn’t really Continuous Integration continuous integration (CI) is the

    practice of merging all developer working copies to a shared mainline several times a day.
  10. This isn’t really Continuous Integration continuous integration (CI) is the

    practice of merging all developer working copies to a shared mainline several times a day. build automation is the process of automating the creation of a software build and the associated processes including: compiling computer source code into binary code … and running automated tests.
  11. This isn’t really Continuous Integration I’m talking about a larger

    scope and a longer timeframe
  12. Is this really Continuous Integration? What checks can I do?

    When can I do these checks? How can I do these checks?
  13. Is this really Continuous Integration? What checks can I do?

    (Scope) When can I do these checks? How can I do these checks?
  14. Is this really Continuous Integration? What checks can I do?

    (Scope) When can I do these checks? (Timeframe) How can I do these checks?
  15. Checks you can do (Scope)

  16. Checks you can do (Scope) • Tests

  17. Checks you can do (Scope) • Tests • Unit tests

  18. Checks you can do (Scope) • Tests • Unit tests

    • Instrumentation tests
  19. Checks you can do (Scope) • Tests • Unit tests

    • Instrumentation tests • Test coverage
  20. Checks you can do (Scope) • Tests • Unit tests

    • Instrumentation tests • Test coverage • Style checks
  21. Checks you can do (Scope) • Tests • Unit tests

    • Instrumentation tests • Test coverage • Style checks • Code arrangement
  22. Checks you can do (Scope) • Tests • Unit tests

    • Instrumentation tests • Test coverage • Style checks • Code arrangement • Code formatting
  23. Checks you can do (Scope) • Tests • Unit tests

    • Instrumentation tests • Test coverage • Style checks • Code arrangement • Code formatting • Method count
  24. Checks you can do (Scope) • Tests • Unit tests

    • Instrumentation tests • Test coverage • Style checks • Code arrangement • Code formatting • Method count • APK size
  25. Checks you can do (Scope) • Tests • Unit tests

    • Instrumentation tests • Test coverage • Style checks • Code arrangement • Code formatting • Method count • APK size • Static code analysis
  26. Checks you can do (Scope) • Tests • Unit tests

    • Instrumentation tests • Test coverage • Style checks • Code arrangement • Code formatting • Method count • APK size • Static code analysis • Code duplication
  27. Checks you can do (Scope) • Tests • Unit tests

    • Instrumentation tests • Test coverage • Style checks • Code arrangement • Code formatting • Method count • APK size • Static code analysis • Code duplication • Code complexity
  28. Checks you can do (Scope) • Tests • Unit tests

    • Instrumentation tests • Test coverage • Style checks • Code arrangement • Code formatting • Method count • APK size • Static code analysis • Code duplication • Code complexity • Profiling
  29. Checks you can do (Scope) • Tests • Unit tests

    • Instrumentation tests • Test coverage • Style checks • Code arrangement • Code formatting • Method count • APK size • Static code analysis • Code duplication • Code complexity • Profiling • Memory profiling
  30. Checks you can do (Scope) • Tests • Unit tests

    • Instrumentation tests • Test coverage • Style checks • Code arrangement • Code formatting • Method count • APK size • Static code analysis • Code duplication • Code complexity • Profiling • Memory profiling • Start-up time profiling
  31. Checks you can do (Scope) • Tests • Unit tests

    • Instrumentation tests • Test coverage • Style checks • Code arrangement • Code formatting • Method count • APK size • Static code analysis • Code duplication • Code complexity • Profiling • Memory profiling • Start-up time profiling • Frame rate profiling
  32. Checks you can do (Scope) • Tests • Unit tests

    • Instrumentation tests • Test coverage • Style checks • Code arrangement • Code formatting • Method count • APK size • Static code analysis • Code duplication • Code complexity • Profiling • Memory profiling • Start-up time profiling • Frame rate profiling • And more…
  33. When can I do these checks?

  34. Normal timeline

  35. Normal timeline

  36. Save Code Normal timeline

  37. Save Code Normal timeline Commit Locally

  38. Save Code Normal timeline Commit Locally Open Pull Request

  39. Save Code Normal timeline Commit Locally Open Pull Request Merge

    code
  40. Save Code Normal timeline Commit Locally Open Pull Request Merge

    code QA
  41. Save Code Normal timeline Commit Locally Open Pull Request Merge

    code QA Release
  42. Work that you do Work done automatically Save Code Commit

    Locally Open Pull Request Merge code QA Release
  43. Work that you do Work done automatically Save Code Commit

    Locally Open Pull Request Merge code QA Release Local Development Code Review After Merge
  44. Assessing cost and value of running a check Quality Bar

    Time
  45. Normal timeline Automatically hook into events Editor hooks git hooks

    Save Code Commit Locally Open Pull Request Merge code QA Release GitHub PR hooks GitHub hooks
  46. Normal timeline Available time and expected quality little time low

    quality little time med quality Save Code Commit Locally Open Pull Request Merge code QA Release med time high quality more time highest quality
  47. Normal timeline For example… catch bugs early Reformat & rearrange

    code FindBugs PMD Lint Save Code Commit Locally Open Pull Request Merge code QA Release Tests & Static Code Analysis Automation Tests
  48. Normal timeline and improve communication! Save Code Commit Locally Open

    Pull Request Merge code QA Release Update ticket statuses Generate release notes
  49. This isn’t really Continuous Integration

  50. Build, Test, Analysis, and Communication Process spanning entire development cycle

  51. Totally Awesome Development Process™

  52. How can I do these checks?

  53. Build • Jenkins • Travis • Circle CI • TeamCity

  54. Build • Jenkins • Travis • Circle CI • TeamCity

    VCS • GitHub • BitBucket
  55. Static Code Analysis • CheckStyle • Findbugs • PMD •

    SonarQube Build • Jenkins • Travis • Circle CI • TeamCity VCS • GitHub • BitBucket
  56. Static Code Analysis • CheckStyle • Findbugs • PMD •

    SonarQube Unit Testing • JUnit • Robolectric Build • Jenkins • Travis • Circle CI • TeamCity VCS • GitHub • BitBucket
  57. Static Code Analysis • CheckStyle • Findbugs • PMD •

    SonarQube Unit Testing • JUnit • Robolectric Build • Jenkins • Travis • Circle CI • TeamCity VCS • GitHub • BitBucket Instrumentation Testing • Espresso • Spoon
  58. Static Code Analysis • CheckStyle • Findbugs • PMD •

    SonarQube Unit Testing • JUnit • Robolectric Build • Jenkins • Travis • Circle CI • TeamCity VCS • GitHub • BitBucket Instrumentation Testing • Espresso • Spoon Crash Reporting • Crashlytics • Firebase
  59. Static Code Analysis • CheckStyle • Findbugs • PMD •

    SonarQube Unit Testing • JUnit • Robolectric Build • Jenkins • Travis • Circle CI • TeamCity VCS • GitHub • BitBucket Instrumentation Testing • Espresso • Spoon Crash Reporting • Crashlytics • Firebase Distribution • Fabric
  60. Static Code Analysis • CheckStyle • Findbugs • PMD •

    SonarQube Unit Testing • JUnit • Robolectric Build • Jenkins • Travis • Circle CI • TeamCity VCS • GitHub • BitBucket Instrumentation Testing • Espresso • Spoon Crash Reporting • Crashlytics • Firebase Distribution • Fabric Multi- functional • BuddyBuild
  61. Static Code Analysis • CheckStyle • Findbugs • PMD •

    SonarQube Unit Testing • JUnit • Robolectric Build • Jenkins • Travis • Circle CI • TeamCity VCS • GitHub • BitBucket Instrumentation Testing • Espresso • Spoon Crash Reporting • Crashlytics • Firebase Distribution • Fabric Multi- functional • BuddyBuild and so many more
  62. A Totally Awesome Development Process™ is

  63. A Totally Awesome Development Process™ is Reliable 24/7

  64. A Totally Awesome Development Process™ is Reliable Comprehensive 24/7

  65. A Totally Awesome Development Process™ is Reliable Comprehensive Informative 24/7

  66. How we do things at eero a mostly free option

    using popular services
  67. Services used at eero

  68. Services used at eero GitHub Industry standard Free public repos

  69. Services used at eero GitHub Industry standard Free public repos

    SonarQube Duplication, coverage, complexity, history, assignment, etc.
  70. Services used at eero GitHub Industry standard Free public repos

    Jenkins Free, customizable, large community SonarQube Duplication, coverage, complexity, history, assignment, etc.
  71. Services used at eero GitHub Industry standard Free public repos

    Jenkins Free, customizable, large community SonarQube Duplication, coverage, complexity, history, assignment, etc. Fabric Convenient, includes release notes
  72. Services used at eero GitHub Industry standard Free public repos

    Jenkins Free, customizable, large community JIRA Specialized for bug and task tracking Has API for updating ticket status SonarQube Duplication, coverage, complexity, history, assignment, etc. Fabric Convenient, includes release notes
  73. Let’s dive into an example! inspired by the eero timeline

  74. Save Code Commit Locally Open Pull Request Merge code QA

    Release Local Development Code Review After Merge
  75. Save Code Commit Locally Open Pull Request Merge code QA

    Release Local Development Code Review After Merge
  76. Save Code Commit Locally Local Development Services

  77. Save Code Commit Locally Local Development Services Android Studio

  78. Save Code Commit Locally Local Development Services Android Studio git

  79. Save Code Commit Locally Local Development Services Android Studio git

    SonarQube
  80. Android Studio • Helpful Plugins • SonarLint • FindBugs, PMD,

    Checkstyle • Share settings for formatting and arrangement • Shortcut for optimizing imports, formatting, and arranging
  81. git • git hooks

  82. SonarQube • Static code analysis at its best. An ultimate

    combination of PMD, FindBugs, Checkstyle, Android Lint, and more! • Tech debt, complexity analysis, code duplication, test coverage • History to track project quality • Caveat: the Android Lint plugin is woefully out of date. It’s still on 22.0 when the latest is >25
  83. SonarQube • Helpful plugins • GitHub Plugin • Android Lint

    Plugin • XML Plugin
  84. None
  85. Save Code Commit Locally Local Development Demo

  86. Save Code Commit Locally Local Development

  87. Save Code Commit Locally Open Pull Request Local Development Code

    Review
  88. Save Code Commit Locally Open Pull Request Local Development Code

    Review Services
  89. Save Code Commit Locally Open Pull Request Local Development Code

    Review GitHub Services
  90. Save Code Commit Locally Open Pull Request Local Development Code

    Review GitHub Jenkins Services
  91. Save Code Commit Locally Open Pull Request Local Development Code

    Review GitHub Jenkins SonarQube Services
  92. GitHub • Show the results of external tasks on a

    commit or pull request
  93. GitHub

  94. Jenkins • Helpful plugins • GitHub Plugin • GitHub Pull

    Request Builder • JUnit Plugin • Gradle Plugin • JIRA Plugin
  95. Jenkins • Useful jobs • Pull Request Builder • Job

    that builds all changes to development branch • Nightly builder
  96. Jenkins • APK size • Method count

  97. None
  98. SonarQube • Run an incremental analysis on just the changes

    • Publish results to GitHub
  99. Save Code Commit Locally Open Pull Request Local Development Code

    Review Demo
  100. The case for an all-in-one solution

  101. • No setup to build pull requests • No setup

    to run tests • Includes crash reporting • Integrate SDK so users can send screenshots of issues • Easily distribute builds to team • Publish directly to the app store
  102. None
  103. Save Code Commit Locally Local Development Open Pull Request Code

    Review
  104. Save Code Commit Locally Local Development Open Pull Request Code

    Review Merge code QA Release After Merge
  105. Merge code QA Release After Merge

  106. Merge code QA Release After Merge Services

  107. Merge code QA Release After Merge Services

  108. Merge code QA Release After Merge Fabric Services

  109. • Integrate with Jenkins to automatically update tickets statuses

  110. None
  111. Fabric • Distribute build to team • Include release notes

    based on the changes since the last Jenkins build
  112. Fabric

  113. Fabric

  114. Merge code QA Release After Merge Demo

  115. The reality

  116. The reality all this requires work and maintenance

  117. The reality all this requires work and maintenance and that

    can be frustrating
  118. The reality

  119. The struggle

  120. The struggle • Build server breaks

  121. The struggle • Build server breaks • Wait time for

    tests and checks to complete
  122. The struggle • Build server breaks • Wait time for

    tests and checks to complete • Pre-commit checks are annoying
  123. The struggle • Build server breaks • Wait time for

    tests and checks to complete • Pre-commit checks are annoying • False-positives in checks
  124. The struggle • Build server breaks • Wait time for

    tests and checks to complete • Pre-commit checks are annoying • False-positives in checks • Rules don’t always apply (e.g. parentheses for improved readability)
  125. it’s easy to get started but configuring everything to your

    needs is harder
  126. enforcing rules improves quality but it requires maturity and discipline

  127. the journey is hard but it’s worth it when you

    get there
  128. I asked some other companies what they do

  129. Do what’s best for your team

  130. Do what’s best for your team by catching bugs early

    and improving communication
  131. Questions? jordan@eero.com