Developer Productivity Engineering Blog
Customer Success

Seven Ways Netflix Uses Develocity to Manage Gradle Plugins

By Doug Tidwell
March 10, 2022

Roberto Perez Alcolea of the Netflix JVM Ecosystem team recently shared some of his team’s use cases and best practices for using Develocity to manage Gradle plugins in their builds. The Nebula project itself is a set of Gradle plugins that eliminate boilerplate build logic and provide sane conventions for simplifying build scripts. 

Roberto’s team manages all of Netflix’s open source Gradle plugins for Netflix internally as well as for the external Nebula community. Tracking how well plugins work or how they’re used by thousands of developers isn’t an easy task. The Nebula team uses Develocity to (1) see how well those plugins are working and performing for their developers and (2) troubleshoot them more easily when things go wrong. 

Here are seven specific ways Roberto says his team uses Develocity to better manage plug-in performance and maintenance:

  1. Time Spend Analysis. It’s very powerful to understand where time is spent, in particular for plugin-level tasks or during configuration time. Develocity gives us great insight on things like the Gradle Resolution Rules plugin or even Nebula itself. We found performance issues across multiple projects. When we combine the times we get from the Build Scan™ and Trends Dashboard data, we can start thinking about where to start profiling if necessary. Sometimes our own plugins cause slowness in builds, so having this data always helps.
  2. Deprecation Visibility. While there is no public API in the Gradle Build tool to include custom deprecations in build scans, we went ahead and used internal ones to start adding Deprecation Warnings to our builds. We found that including deprecation warnings in Build Scans has been helpful. This is good if you have features in plugins and try to start deprecating things in advance (which you should), especially when you don’t have automation for linting build files or full control over them. (Note: starting in Gradle V6.0, deprecation warnings are always included in a Build Scan). In addition, we are planning to use the Develocity Export API to collect common deprecations across builds and know who is contributing to them, for example, a plugin, a script or even a task. We believe this is a great way to understand our ecosystem and prioritize migrations accordingly.
  3. Migration Candidate Identification. We already use the Develocity Export API to publish information about plugins being used at Netflix. We store that in Elastic Search, then use a dashboard we composed to see how many projects use a particular plugin, along with the version of that plugin and the version of Gradle they’re using. This helps us identify projects that should be migrated to a more recent version of the plugin. 
  4. Local Build Troubleshooting. Using the Build Scan service is a great way to support our team and boost their productivity. Before Develocity, we could look into CI jobs to get some insights, but the painful part, of course, was trying to troubleshoot failures in a developer’s local environment. The Build Scan gives us more details on plugin versions as well as errors, the execution environment, dependency classpaths, and other useful information. All of that speeds up troubleshooting considerably. 
  5. Regression Observability. By tagging builds properly we can filter down information for things like local versus CI builds or for uses of one framework versus another. We also tagged builds that use deprecated plugins (Findbugs, for example) so we understand how many projects are using them. That allows us to see build trends over time so we can see if we introduced regressions. Even better, we can tell when we introduced them. 
  6. Proactive Pattern Detection and Failure Remediation. We review the ‘Failures’ tab every week. This really helps us understand non-verified errors coming from builds. We can also detect patterns so we can accommodate those in our plugins. For example, we have found cases where builds fail because the Test task filters are not well applied. Often teams don’t notice that sort of thing. Now we can reach out to our developers so they can fix those hidden issues before they cause problems. 
  7. Task Failure Detection. Develocity lets us detect task failures associated with either external or internal plugins. We can see which versions of various Gradle and Nebula plugins are used by projects. This helps us find ways to help the development team recover. 

Roberto’s team uses Develocity to improve the lives of developers at Netflix and in the Nebula community around the world. Our thanks to Roberto for sharing his insights and experiences.