Gradle is an open-source build automation tool focused on flexibility, build reproducibility and performance. Over the years, this tool has evolved and introduced new concepts and features around dependency management, publication and other aspects on build and release of artifacts for the Java platform. Keeping up to date with all these features across several projects can be challenging. How do you make sure that all your projects can be upgraded to the latest version of Gradle? What if you have thousands of projects and hundreds of engineers? How can you abstract common tasks for them and make sure that new releases work as expected? At Netflix, we built Nebula, a collection of Gradle plugins that helps engineers remove boilerplate in Gradle build files, and makes building software the Netflix way easy. This reduces the cognitive load on developers, allowing them to focus on writing code. In this talk, I’ll share with you our philosophy on how to build JVM artifacts and the pieces that help us boost the productivity of engineers at Netflix. I’ll talk about: - What is Nebula - What are the common problems we face and try to solve - How we distribute it to every JVM engineer - How we ensure that Nebula/Gradle changes do not break builds so we can ship new features with confidence at Netflix

1. Keeping your build
tool updated in a
multi repository
world
April 10, 2024

2. Roberto Perez Alcolea
Senior Software Engineer @ Net
fl
ix
JVM Ecosystem Team
rperezalcolea@net
fl
ix.com
@rpalcolea

3. ⚠ ⚠ Spoiler Alert ⚠ ⚠

4. vs
Not a “the best build tool” talk

5. But some learnings might apply for other tools
Usage of

6. — Why care about the build tool?
— Why Netflix uses Gradle
— Challenges of using Gradle
— How do we address the
challenges
— Few tips
— Q&A
Agenda

7. Why care
about the
build tool?

8. Flow State
Image from https://about.sourcegraph.com/blog/developer-productivity-thoughts

9. Mental context switches =
out of Flow state
Image from https://about.sourcegraph.com/blog/developer-productivity-thoughts

11. 💡 It’s all about providing
the best developer
experience and improve
productivity 💡

12. But also…

13. ⚠ ⚠ ⚠ ⚠ ⚠ ⚠ ⚠ ⚠ ⚠ ⚠
Free and Open Source
Software (FOSS)
constitutes 70-90% of any
given piece of modern
software solutions
⚠ ⚠ ⚠ ⚠ ⚠ ⚠ ⚠ ⚠ ⚠ ⚠
A Summary of Census II: Open Source Software Application Libraries the World Depends On

14. Images from https://www.sonatype.com/state-of-the-software-supply-chain/introduction
There are risks…

15. Examples…
— Resources Downloaded over
Insecure Protocol
(CVE-2021-26291)
— Arbitrary code execution via
specially crafted environment
variables (CVE-2021-32751)
— Dependencies used by external
plugins or the plugins
themselves
🔐 You should follow Jonathan Leitschuh’s (@JLLeitschuh) work! 🔐

16. Why Netflix
uses Gradle

17. In 2013, Netflix software was built using
an Ant and Ivy based solution we called CBF (Common
Build Framework)

18. 🚀 🚀 🚀 🚀 🚀 🚀 🚀 🚀 🚀 🚀
Netflix accelerated growth
🚀 🚀 🚀 🚀 🚀 🚀 🚀 🚀 🚀 🚀

19. We started looking for a build tool that:
— Better dependency management
Enabled testability
— Provided first class support for
Java applications
— Rich community and ecosystem
— Allowed us to vastly simplify build
files

20. years…

21. JVM Ecosystem landscape
— ~4.2k repositories
— ~1.1k developers using
JVM languages
— Thousands of applications
— Microservices with fat
clients
— Binary integration (JARs)

22. JVM Ecosystem landscape

23. JVM Ecosystem landscape
— Build stats
• ~215k JVM Builds per
week
• ~91k local
• ~124k on CI

24. Gradle continues providing
amazing features
— Build Caching
— Configuration Caching
— Advanced Dependency
Management
— Incremental Builds
— Incremental Tasks
— Filesystem Watching
— Toolchains

25. Challenges of
using Gradle
“at scale”

26. Developers might not want to learn
build tools

27. Duplicated logic across projects

28. Keeping up with the release cadence
— Latest: Gradle 8.7 (March 2024)
— Aiming for:
• Major release every year
• Gradle 9.x ~Q3 2024
• Minor release every 6 weeks
• The major version before the
previous one to become end-of-
life (EOL)

29. Breaking changes
Be aware of the feature states!
• Internal (don’t use them)
• Incubating (provide feedback)
• Public (safe to use)
• Deprecated (act as soon as
possible)

30. Adopting new features
• How fast can you adopt
new features?
• Should you adopt all of
them?

31. Java Compatibility
Image from https://docs.gradle.org/current/userguide/compatibility.html
Compatibility varies for:
— Compile and test code
— Running Gradle
• Groovy or Kotlin DSL
• Plugins

32. Plugin ecosystem
There are more than 7000 plugins in the Gradle Plugin portal

33. Plugin ecosystem
— New version support
— Backwards compatibility
— Usage of deprecated APIs/
Features
— Third-party plugins can be
abandoned

34. 🤔 Most likely similar
problems as with any
other framework or tool 🤔

35. How do we
address the
challenges

36. Create project plugins for common tasks
Good for:
— Packaging
— Publishing
— Compilation/Test opinions
— Static code analysis
— Bundle other plugins
— Versioning

37. Create project plugins for common tasks
Types of plugins:
— Script
— Convention
— Binary (great for
multiple repositories)

38. Create Settings plugins
Good for:
— Configure Develocity
features
— Java Toolchain resolvers
— Plugin Management
opinions

39. Create Settings plugins
Example from https://github.com/gradle/foojay-toolchains

40. Create Init plugins
Good for:
— Add dependencies to build
script classpath
— Modify repositories for all
projects
— Any settings that apply
globally to all builds on a
machine

41. Example from https://github.com/gradle/foojay-toolchains
Create Init plugins

42. And you end with…
🤔

43. 💡 You should consider a
company gradle
distribution 💡

44. We created

45. 💥 Nebula is collection of
project, settings and init
plugins bundled as a
custom distribution 💥

46. Example from https://github.com/gradle/foojay-toolchains
What developers see

47. What developers get
— Linting
— Dependency Locking
— Resolution Rules
— Dependency Graph Manifests
— Develocity configuration
— And many more…
— Spring Boot plugin default
configurations
— Debian generation
— Docker image generation
Versioning
— Internal Repositories
— Testing opinions
— Publishing credentials and
configuration
— Static code analysis defaults
Example from https://github.com/gradle/foojay-toolchains

48. Custom Distribution isn’t as complex as it sounds
Creating a custom distribution is in a
nutshell
- Download Gradle
- Unzip it
- Copy your init script and
gradle.properties files to init.d
- Zip it again
- Use it

49. It isn’t as complex as it sounds
This is thanks to Gradle init script management
Content from https://docs.gradle.org/current/userguide/init_scripts.html

50. How to create it then?
Demo can be found in https://github.com/rpalcolea/devnexus-2024-demos/tree/main/custom-distribution-demo
There is a custom-gradle-dist-gradle plugin!

51. But even with all the
plugins in the world, you
still need to maintain
build scripts…

52. Linting build files
Demo can be found in https://github.com/rpalcolea/devnexus-2024-demos/tree/main/nebula-lint-demo

53. And we need to make
sure things work

54. Acceptance testing
Niagara clones every repository and
runs some commands to:
— Upgrade Nebula (Gradle)
• Candidates
• Snapshots
— Upgrade Gradle for OSS plugins
that we use

55. Acceptance testing

56. And still, we need to
upgrade our ~4k
repositories

57. Automating changes
Nightly or on-demand pull requests for:
- Dependencies
- Nebula Wrapper
- Lint

58. What if you don’t want to build this?

59. If you use Build Scans

60. Find deprecation warnings to address them

61. Use performance information to decide
where to invest

62. If you use Develocity
(formerly Gradle
Enterprise)

63. Use failure analytics to understand
potential regressions from your plugins
Example can be found in https://ge.gradle.org/scans/failures

64. Take advantage of the Export API
You can learn which and how plugins are used

65. Take advantage of the Export API
Understanding the long tail of versions for plugins is important

66. Few tips

67. Define your commitment
- Trying out snapshots and RCs
really helps Gradle team to
identify issues but not everyone
have the time to do it and that is
fine.
- You can have different
approaches based on the release
type (e.g. adopt minor and patch
release quickly but major versions
take more time)

68. Write plugins in Java
You might thank me later! 😉

69. Gradle TestKit is your friend

70. Test your plugin with
multiple Gradle versions
The Gradle Test plugin extends the power that the new GradleTestKit brings
without having to actually author code!

71. ⚠ Only introduce incubating
APIs in your plugins if you
know that all your
consumers are compatible ⚠

72. Similar to other projects,
avoid adding third party
dependencies when they are
not necessary

73. Same applies to plugins, look
at the activity of them before
introducing to your builds,
they can be a major blocker
for evolving your toolkit

74. Gradle Community
Images from https://gradle.org/fellowship/
- Join the Gradle Community Slack
https://gradle.org/slack-invite/
- Gradle Fellowship: these folks are
very active in the slack community
and also generate a lot of
educational material

75. Nebula plugins
- https://github.com/nebula-plugins
- Notable plugins:
- gradle-int-plugin
- gradle-esolution-rules-plugin
- gradle-jakartaee-migration-
plugin

76. Reiterating a bit…
— Gradle is a build tool with many
great features but you might not
need all of them, invest where
possible
— From project plugins to custom
distribution, there are ways to
abstract complexity and
standardize build tooling for
teams/orgs
— Keeping Gradle up to date can be
challenging but it is important not
only for the developer experience
but also for security concerns.
Prioritize accordingly

77. Questions?

78. Thank
You.
Roberto Perez Alcolea
rperezalcolea@net
fl
ix.com