Developer Productivity Engineering: What’s in it for Java Developers?

Slide 1

Developer Productivity Engineering What’s in it for Java Developers?

Slide 2

Slide 3

Who is this guy? @BrianDemers | bdemers

Slide 4

source: Silicon Valley @BrianDemers | bdemers

Slide 5

VS @BrianDemers | bdemers

Slide 6

VS @BrianDemers | bdemers

Slide 7

Developer Productivity Engineering @BrianDemers | bdemers

Slide 8

@BrianDemers | bdemers

Slide 9

Slide 10

Code Code Wait Time for Local Build Debug Build Failure Lunch Code Sprint Wait Time for Local Build Waiting time for CI Build Investigate/Fix Flaky Tests Bottlenecks to Productivity are Everywhere

Slide 11

“Bottlenecks in the toolchain are holding back the rockstar 10x developers” Pete Smoot, Software Architect, Dell Technologies It’s True at Dell, and Everywhere Else

Slide 12

Developers code 52 minutes per day https://www.software.com/reports/code-time-report @BrianDemers | bdemers

Slide 13

DPE is a new software development practice used by leading software development organizations to maximize developer productivity and happiness. Gradle is Pioneering DPE

Slide 14

Slide 15

xkcd.com/303 This Doesn’t Have To Be Our Reality

Slide 16

source: https://www.cshl.edu/quiz/brain-interrupted/ @BrianDemers | bdemers

Slide 17

What Problems Does DPE Solve? This takes too long! This takes too long to fix This should have been observable

Slide 18

Slide 19

Blank use will Builds background and Tests Take Tooat Long! Blank background use at will

Slide 20

The anatomy and importance of fast feedback cycles PRODUCTIVITY Less idle/ wait time Less context switching More focused developers QUALITY FASTER FEEDBACK CYCLES More frequent builds KEY: Earlier quality checks Fewer downstream incidents Smaller change sets Few merge conflicts New behavior Effect KEY BENEFIT More efficient troubleshooting Faster MTTR

Slide 21

Faster Builds Improve Creative Flow No. of Devs Build Time No. of local builds Team 1 Team 2 11 6 4 mins 1 mins 850 1010

Slide 22

Multiple Acceleration Technologies are Best

Slide 23

Build caching delivers fast build and test feedback cycles

Slide 24

Build Caching ⬢ Introduced to the Java world by Gradle in 2017 ⬢ Maven has an open source build ⬢ Build caches are complementary to dependency caches, not mutually exclusive: ○ dependencies cache too ⬢ Used by leading technology ○ Can support both user local and remote caching for distributed teams A build cache accelerates building a single source repository companies like Google and Facebook ⬢ A dependency cache caches fully compiled ○ A build cache caches build actions (e.g. Gradle tasks or Maven goals)

Slide 25

What is a Build Cache? Inputs ● Gradle Tasks ● Maven Goal Executions Outputs When the inputs have not changed, the output can be reused from a previous run.

Slide 26

Cache Key/Value Calculation The cacheKey for Gradle Tasks/Maven Goals is based on the Inputs: cacheKey(javaCompile) = hash(sourceFiles, jdk version, classpath, compiler args) The cacheEntry contains the output: cacheEntry[cacheKey(javaCompile)] = fileTree(classFiles) For more information, see: https://docs.gradle.org/current/userguide/build_cache.html

Slide 27

Remote Build Cache Savings at Dell 41% Savings from Cache

Slide 28

https://reproducible-builds.org/

Slide 29

fi Predictive Test Selection leads to greater ef ciencies

Slide 30

https://research.facebook.com/publications/predictive-test-selection/

Slide 31

Conventional Test Selection Approach

Slide 32

Predictive Test Selection Approach 4% 3% 2% 2% 98% 96%

Slide 33

Predictive Test Selection Savings at Dell 7 Day Period 41 Days Testing Savings Predicted

Slide 34

Test distribution can make tests even faster

Slide 35

How it works Autoscaler

Slide 36

Existing solutions - CI fanout Test execution is distributed by manually partitioning the test set and then running partitions in parallel on several CI nodes. pipeline { stage(‘compile’) { … } parallelStage(‘test’) { step { sh ‘./gradlew :testGroup1’ } step { sh ‘./gradlew :testGroup2’ } step { sh ‘./gradlew :testGroup3’ } } } https://builds.gradle.org/project/Gradle for an example of this strategy See

Slide 37

Assessment of existing solutions ⬢ Build Caching is great in many cases but doesn’t help when test inputs have changed. ⬢ Single machine parallelism is limited by that machine’s resources. ⬢ CI fanout does not help during local development, is inefficient (in particular on ephemeral CI agents or without build cache), requires manual setup and test partitioning, and result collection/aggregation

Slide 38

Build Scans speeds up troubleshooting

Slide 39

Improved Troubleshooting

Slide 40

Build Scan - scans.gradle.com

Slide 41

Without focus, problems can sneak back in… ⬢ ⬢ Infrastructure changes ○ Binary management ○ Caching ○ CI agents New annotation processors or versions of annotation processors ⬢ Build logic configurations settings ○ Build tool version and plugins ○ Compiler and/or Memory settings ⬢ Code refactoring ⬢ New office locations ⬢ Without observability, it is impossible to have a great and fast developer experience.

Slide 42

“ You canBlank observe a lot by watching.” background usejust at will

Yogi Berra, Catcher and Philosopher

Slide 43

Performance Insights Are you tracking local build and test times?

Slide 44

DPE Organizations Track Build and Test Times

Slide 45

DPE Organizations Track Failure Rates

Slide 46

Flaky Tests Are Everywhere 7 day period Test Flaky 299 times

Slide 47

Dealing with Flaky Tests The test is flaky. What do you do now? a. Try it again b. Re-run it c. Re-run it again d. Ignore it and approve PR e. All of the above