Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Blazing Fast Feedback Loops in the Java Universe

219 views

Published on

We all know that fast feedback loops make a real difference and that they are the most important part of agile development in general. This is why I want to take you on a tour of a variety of ways to increase quality and optimize feedback loops that I’ve encountered in the JVM-based projects that I’ve worked on so far.

Published in: Engineering
  • Be the first to comment

  • Be the first to like this

Blazing Fast Feedback Loops in the Java Universe

  1. 1. Michał Kordas Blazing Fast Feedback Loops in the Java Universe
  2. 2. FEEDBACK DO A THING CHECK HOW IT WENT DO NOT BUILD ON ASSUMPTIONS
  3. 3. CONTEXT • Small team • All use IntelliJ IDEA • ~30 repositories • Java, Groovy, Scala • Maven, Groovy • Jenkins • GitHub
  4. 4. WHAT YOU DO WHEN…? • broken environment • not meaningful exception • struggling with technology • struggling with project • style-related comment during code review
  5. 5. EVERY TIME WHEN FEEDBACK COMES TOO LATE TRY TO MAKE IT FASTER
  6. 6. BROKEN ANYTHING? ADD A HELL LOT OF HEALTH CHECK BUILDS
  7. 7. NOT MEANINGFUL EXCEPTION? FAIL FAST CATCH EXCEPTION OR THROWABLE ADD CONTEXT AND RETHROW OR YOU’LL DIE
  8. 8. STRUGGLING WITH TECHNOLOGY? ASK ON STACKOVERFLOW (AND ANSWER BY YOURSELF)
  9. 9. STRUGGLING WITH PROJECT? ADD TO KNOWLEDGE BASE README.md wiki
  10. 10. STYLE ISSUES DURING CODE REVIEW? ADD TASK TO AUTOMATE NEXT TIME
  11. 11. COMPILER WARNINGS http://programmers.stackexchange.com/questions/94754/how-do-i- convince-my-teammates-that-we-should-not-ignore-compiler-warnings
  12. 12. COMPILER WARNINGS
  13. 13. PREVENTING COMPILER WARNINGS
  14. 14. DEPENDENCY UPDATES
  15. 15. MONITORING DEPENDENCY UPDATES MAVEN GRADLE HOW? • tool that invokes the above commands in all repositories • report for developers is created periodically
  16. 16. COMMIT MESSAGES "git log origin/master..HEAD".execute().text
  17. 17. BUILD STATUS
  18. 18. JENKINS CI BUILD MONITOR PLUGIN https://github.com/jan-molak/jenkins-build-monitor-plugin
  19. 19. SIREN OF SHAME https://sirenofshame.com/
  20. 20. GITGUARD Chrome extension blocking GitHub merge button based on specified Jenkins jobs https://chrome.google.com/webstore/detail/ gitguard/dlbacfedgdjanlkofjckclmgmijbhakl
  21. 21. NO RED MASTER PLEASE! • Run all tests on branches • Use GitHub Status API • Merge master before running tests
  22. 22. ENFORCE UP-TO-DATE • Enforce branch to be up-to-date before merge
  23. 23. SHIELDS AND BUTTONS
  24. 24. UNIT TESTS Fast (hundreds per second, run in parallel) Isolated (single unit tested) Repeatable (always the same result) Self verifying (either pass or fail) Timely (written early) FIRST BLAZINGLY FAST AND ULTIMATELY RELIABLE TESTS mvn test gradlew test SHIFT+F10
  25. 25. PARALLEL TESTS CONFIGURATION
  26. 26. PARALLEL BUILD CONFIGURATION
  27. 27. GRADLE PERFORMANCE TIPS mavenCentral() jcenter() USE DAEMON UPDATE TO LATEST GRADLE gradlew wrapper –gradle-version 3.1 gradlew build --profile USE JCENTER PROFILE GRADLE BUILD SCANS COMPILE INCREMENTALLY compileJava.options.incremental = true
  28. 28. CODE STYLE / STATIC ANALYSIS • Checkstyle, PMD, FindBugs, CodeNarc • Agree on common rules for all projects • Shared configurations • Gradle plugin • Maven plugin • Maven parent POM (tricky)
  29. 29. INTERNAL QUALITY PLUGIN • Integrates all agreed tools with all reasonable rules enabled • Customized for project/company needs • Zero configuration by default • Unified console output with clickable links gradlew checkstyleMain pmdMain findbugsMain codenarcMain checkstyleTest pmdTest findbugsTest codenarcTest gradlew quality
  30. 30. BLACKLISTS • Use blacklists instead of whitelists to get new rules PMD FindBugs CodeNarc
  31. 31. EARLY STATIC ANALYSIS FEEDBACK • CheckStyle-IDEA • FindBugs-IDEA • SonarLint
  32. 32. GATHER VIOLATIONS FROM ALL TOOLS AND MODULES gradlew quality --continue mvn -fae mvn --fail-at-end
  33. 33. GRADLE BASE PLUGIN • Applies ‘java’, ‘groovy’ and ‘maven’ plugins • Always shows full stacktraces, even if --stacktrace is forgotten • Adds provided configuration (missing in Gradle) • Configures repositories with dependencies • Adds tuned compiler configuration for Java and Groovy • Displays detailed information about all warnings (-Xlint:all option) • Fails build on any unsuppressed warning (-Werror option) • Adds configuration to run tests in parallel • Enables rich test logging with summary • (Tests run: 3, Failures: 2, Skipped: 1) and full stacktraces • Configures wrapper task with latest Gradle • Applies taskTree plugin • Applies com.github.ben-manes.versions plugin • Prints Gradle and JVM versions in the output
  34. 34. SANITY BUILD MATRIX Periodically run on master series of builds using different configurations that developers may use • various Java and Maven versions • various build parameters like -DskipTests • various JVM params like locale • compilation with fresh repository
  35. 35. MUTATION TESTING • Mutations are made to the code • If tests fail then the mutant is • If tests pass then the mutant • Percentage of mutants killed is indicator of your tests quality • Can be really killed lived slow!
  36. 36. FAST MUTATION TESTING scmMutationCoverage GitHub status Report
  37. 37. NON-REQUIRED CHECKS https://help.github.com/articles/about-required-status-checks/
  38. 38. NONDEX • Tool for detecting wrong assumptions about Java APIs • assuming specific order of HashMap iteration • Run tests with changed implementations of standard classes to return shuffled results • Same happens when upgrading Java
  39. 39. APIS ANAYZED BY NONDEX
  40. 40. PLAY WITH COMMITTING .IDEA FILES
  41. 41. PROVISION NODES AUTOMATICALLY
  42. 42. GET STATUS ON PULL REQUESTS QUICKLY
  43. 43. PIPELINES https://wiki.jenkins-ci.org/display/JENKINS/Build+Pipeline+Plugin gradlew build
  44. 44. CODE REVIEW • Do timely • Assign people • Internal team review • External review • Address comments
  45. 45. OPEN PULL REQUESTS DASHBOARD https://github.com/pulls
  46. 46. CONTRIBUTING FILE create CONTRIBUTING.md in repository root be notified
  47. 47. QUALITY OF FEEDBACK
  48. 48. RETROSPECTIVES
  49. 49. RETROSPECTIVES IF IT IS NOT FUN, YOU'RE DOING IT WRONG
  50. 50. DIALOGUE SHEETS https://www.softwarestrategy.co.uk/dialogue-sheets/
  51. 51. CONSTANT IMPROVEMENT
  52. 52. SUMMARY • We want feedback to • continuously improve • deliver more value • reduce risk • learn • Feedback has • many types • many sources
  53. 53. THERE IS NO FAILURE. ONLY FEEDBACK. Robert Allen

×