Presented by: Justin Reock & Sterling Greene Presented at the All Things Open 2021 Raleigh, NC, USA Raleigh Convention Center Abstract: In 2007, Hans Dockter invented the Gradle Build Tool because he felt that developers deserved less friction in their toolchain. The prevailing build technologies of the time were adequate but inefficient, not taking advantage of possible acceleration technologies and, with some exceptions, very limited in their language and framework support. Gradle is now one of the most widely used build tools available, downloaded about 25 million times a month as of September of 2021. It’s the default build tool in Android Studio, and is trusted by millions of developers to create their artifacts quickly and cleanly. The principles that originally guided the Gradle build tool towards its current popularity have continued into an emerging practice known as Developer Productivity Engineering or DPE. DPE is a new software development practice that uses acceleration technologies to speed up the software build and test process and data analytics to optimize the impact of acceleration technologies and make troubleshooting more efficient. Leading technology companies are using this practice today to accelerate feedback cycles by over 90% in some cases, improving the developer experience and increasing team velocity. Join Sterling Greene, Lead Software Engineer for the Gradle Build Tool, and Justin Reock, Field CTO of Gradle Enterprise, to learn why DPE is swiftly becoming the most important movement in software development since the introduction of DevOps. Attendees will walk away from this presentation with a better understanding of: ● The importance of fast feedback cycles and how to achieve them using build and test acceleration technologies ● Using build and test data to make troubleshooting and problem root cause determination more efficient. ● The importance of leveraging failure analytics to improve toolchain reliability, including managing avoidable failures like flaky tests. ● How to continuously improve performance and guard against regressions through trend and metric observability. ● The Cost of Inaction (CoI) by not investing in developer productivity across your local build environments and CI/CD pipelines in terms of engineering cost, TTM and software quality. ● How to elevate the strategic priority of DPE in your organization.

1. Developer Productivity Engineering
With Gradle
Enterprise

2. Your Speakers
Justin Reock
Chief Evangelist and Field CTO
Gradle Enterprise
Sterling Greene
Lead Software Engineer
Gradle Build Tool

3. Gradle Inc
Gradle Build Tool
⬢ Most used build tool for new open-source JVM projects on GitHub
⬢ Official build tool for Android
⬢ Over 20 million downloads per month
⬢ One of the top 20 open-source project according to TechCrunch
Build Scan™
⬢ Shareable, rich web interface with detailed build information
⬢ Free to use in Gradle cloud
Gradle Enterprise
⬢ On-premises
⬢ Visibility into all builds in the organization, both local and CI
⬢ Build cache backend with statistics and node management

4. What makes Gradle build tool fast?
⬢ Daemon
⬢ Parallelism
⬢ Work avoidance
⬢ Incremental compilation
⬢ Compilation avoidance
⬢ Incremental builds
⬢ Build cache

5. Incremental Builds

6. Build Caching
⬢ Introduced in 2017.
⬢ Available for Maven and Gradle, can support both user local
and remote caching for distributed teams
⬢ Build caches are complementary to dependency caches, not
mutually exclusive:
○ A dependency cache caches fully compiled
dependencies
○ A build cache accelerates building a single source
repository
○ A build cache caches build actions (e.g. Gradle tasks or
Maven goals)

7. Build Cache

8. Blank background use at will
Build caching is a tool for very fast feedback cycles

9. Measurements with OSS Projects
Running on a MacBook Pro (16-inch, 2019)
Project uncached fully cached
Gradle @ 9c93f04
4 minutes 13 seconds
gradle compileAll
Spring Boot @ 9ff17edb
4 minutes 24 seconds
gradle assemble

10. Demo: Speeding up local Builds
⬢ Run a clean build with no cached elements
⬢ Re-run the build with local caching on and elements cached

11. A Day in the Life of Enterprise Developers
Code
Code
Wait Time for Local Build
Debug Build Failure
Lunch/Ping Pong
Code
Wait Time for Local Build
Investigate/Fix Flaky Tests
Sprint
Waiting time for CI Build

12. What problem are we trying to solve?

13. Software development is a creative process

15. Our mission at Gradle is to accelerate developer
productivity and make developers happier

16. Project success negatively impacts toolchain
efficiency
In successful projects all those metrics are growing, often exponentially:
⬢ Lines of Code
⬢ No. of developers
⬢ No. of repositories
⬢ No. of dependencies
⬢ Diversity of tech stack
Result:
⬢ Toolchain efficiency severely degrades if unmanaged
⬢ The return of growing the team becomes more and more marginal

17. Blank background use at will
“ It’s no longer the big beating the small,
but the fast beating the slow.”
Eric Pearson, CIO, InterContinental Hotels Group

18. What comes after DevOps?

19. Introducing Developer Productivity
Engineering
⬢ So, when we say Developer Productivity Engineering is the ‘next thing,’ we mean that
literally
⬢ Using acceleration technologies and data accumulation and analysis technologies, DPE
addresses the next set of bottlenecks in software productivity
⬢ Friction and slowdowns in the developer experience, caused by unreliable and/or slow
build infrastructure represent productivity black holes that are not in scope for DevOps

20. DPE != DPM

21. Faster builds improve the creative flow
Team 1 Team 2
No. of Devs 11 6
Build Time 4 mins 1 mins
No. of local builds 850 1010
⬢ The faster the feedback is, the more often devs ask for feedback
⬢ The more often they ask for feedback, the more they can refine their work

22. Builds that are faster than 10 mins cause significant
waiting time
⬢ Slower builds means developers are often context-switching while build and tests finish
⬢ The aggregated cost of waiting is surprisingly high even for faster cycles
⬢ Even moderate improvements are worthwhile at scale to reduce idle time
⬢ A unreliable toolchain substantially increases waiting time!
No of devs Local builds per week Build Time Build Time w. GE Savings per year
6 1010 1 mins 0.6 mins 44 days
100 12000 9 mins 5 mins 5200 days

23. Build Cache and
Test Distribution
• Faster feedback
cycles by caching
build tasks
• Parallel test
execution,
decrease time
spent testing
Build Scans
• Shareable root
cause analysis tool
• Full X-ray of build
with context
Failure Analytics
• View build and
test failure rates
and history
• Find flaky tests
and unreliable
build
infrastructure
Trends and Insights
• Spot inefficiencies
and outliers
• Gauge success of
initiatives
CI Cache and
Resource Profiling
• Speed up CI builds
• Determine causes
of stress on CI
environments
DPE Solution Breakdown

24. “Perhaps the best part of using the Gradle Build
Scan is that it provides direct links to the relevant
parts of the official documentation from Gradle
which are more of the Friendly Manual kind.”
–Jean-Michael Fayard, Writer, Kotlin Academy
• Build scans provide a
comprehensive, shareable build
summary
• It’s easy to spot bugs and failures,
and is self-service to the developer
• Developers can share build details
with context
• Scans can run against Gradle and
Maven builds by adding a free
extension
Build Scan™

25. Creating a build scan with Gradle
Maven .mvn/extensions.xml
<extensions>
<extension>
<groupId>com.gradle</groupId>
<artifactId>gradle-enterprise-maven-extension</artifactId>
<version>1.11</version>
</extension>
</extensions>
Gradle CLI
Free Build Scan service: https://scans.gradle.com/

26. Demo: Creating a build scan
⬢ Generate an example build with gradle init
⬢ Create a build scan with gradle build –scan
⬢ Example Gradle build scan
⬢ Example Maven build scan

27. Problems can sneak back into the build process
⬢ 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 settings
○ Memory settings
⬢ Code refactoring
⬢ New office locations
Performance

28. Blank background use at will
“ You can observe a lot by just watching.”
- Yogi Berra, Catcher and Philosopher

29. Encouraging continuous improvement

30. “If you can’t measure it, you can’t improve it.”
- Peter Drucker, Business Luminary
• Test and build results can be
compared across runs, surfacing
common failures and flaky tests
• By finding flakiness further left,
we reduce developer
frustration and the number of
bugs
• By pinpointing common
failures, we can eliminate them
before developers encounter
them
Failure Analytics

31. “How does a project get to be a year late? One day
at a time.”
-Fred Brooks, Renowned Software Engineer, IBM
• DPE PMO should centralize build
metrics
• This enables the DPE PMO to
continually improve productivity
• Build feedback is automatically
provided to the DPE PMO team
each build, whether locally or
remotely across the entire
organization!
Trends and Insights

32. Demo: Gradle Build Tool DPE Dashboard
⬢ Visit https://ge.gradle.org
⬢ Testing trends
⬢ Individual scan with a test failure

33. https://gradle.com/developer-productivity-engineering/
Reminder: BE A HERO!
Be the first to introduce DPE
to your business!

34. Q
&
A
Next Steps:
● Try a free Maven or Gradle Build Scan!
(Hint: Just enable the Maven extension or
run ’gradle build –scan’)
● Read about Build Scans and Build
Comparisons: https://gradle.com/gradle-
enterprise-solution- overview/build-scan-root-
cause-analysis-data/

35. Gradle swag

36. Thank you!
sterling@gradle.com
jreock@gradle.com