From mobile apps to microservices, from small startups to big enterprises, Gradle helps teams build, automate and deliver better software, faster.

Gradle Community

The biggest things are really the cross-system integrations, linking tasks/bugs with triage systems with internal social media and chat ops with automated bot frameworks so that devs aren't having to think about how each system looks at what is really the same data or code. Put another way: A diff is a diff is a diff regardless of what context you reference it from

Thats a really great point and I can see how that helps remove toil and remove friction from their work. Thank you.

I wouldn't say it's "misleading." But that it's about what works rather than some ideal of how it "should be done." In general, we think along the lines of a product (like Reels or Gaming) rather than in terms of apps (Like Facebook or Instagram) and it really makes no sense to split a product into two repos when the experience is supposed to be consistent. In practice we divide some platform-specific code (android vs oculus vs iOS) but keep as much cross-platform as we can. That's part of why we've built libraries like React Native so that we aren't having to rewrite code for each application and platform.

I mean the answer is always "not enough" in the android world. With thousands of target devices it's not practical to test on all of them. That said, this is part of why a public beta is so critical to stabilizing the app.

It depends a lot on how the experience is delivered. We have some experiences that are defined by the server and those changes go to users hundreds of times a day, the app stores are pretty restrictive as to what kinds of things we can ship in that model though, so the typical change is in human hands in about a day, in the public beta within the week, and released to the world 3-7 days after the beta depending on the app. All told a average change to the app takes 7-9 ish days from commit to full release

We measure everything we can measure. Because we run a weekly beta release cycle and we cut on the same day, the lead time is knowable even before you commit as the time from "now" until the cut. We cut alpha once a day every day, so in general some human is seeing the new code by tomorrow.

As a rule, I try to de-emphasize devs structuring their work around the release cycle as it incentivizes last-minute heroics. While the realities of the app stores dictate a weekly cycle, It's better in the long run to ignore that and set a quality/functional bar for code rather than a timeline

There's a common mantra at Meta that "nothing is someone else's job" everyone has an area of focus and we largely let people decide how best to have impact in that area. The allocation of head count between orgs is something I don't have much insight into, but I can say that we always have headcount open on both sides and when "more people" will solve a measurable problem, we are pretty god at getting more people to work on it.

It would if we really were waiting on the land. We automate so much around the process that it doesn't have to be watched closely. Most of the time a diff is fire-and forget and when it fails or breaks something our tooling will notify us.

We also ship with what we call "stacks" which are sequences of dependent diffs, so if you really really have to have one diff land after another they can both be "landed" without the possibility of racing each other

That could be a talk by itself. We have local testing of course, E2E and integration and unit tests. We also have tests that run on every revision to a diff, so you can push changes up to your diff (even if it's not published) and then the infrastructure will run a modest test suite for you. There are on-demand ad-hoc options that we can initiate for a diff beyond the basic suite, and we can also run the full land-blocking suite in a "dry-run" mode.

Great stuff. Thanks for taking the time to do the talk as well, really appreciate the insights, and color.

Could you dive a bit deeper into the local testing aspect? I assume this means the ability to generate builds locally itself, and wondering how this can happen more or less fast each time for what I image is a huge build or multiple builds. 


<@U037G4C0Q1K> in a word, caching. We only rebuild artifacts when we absolutely have to and we maintain a "stable" point that trails master by a couple hours at any given time. So long as you're working from the stable point, local builds are quite fast. This enables us to locally apply just about anything from our test suite and do local validation of changes.

Sure. First and foremost, it's worth reiterating that we goal on company health metrics more than productivity so these are measures we try to improve but not independent of those. Sad Users , time spent, and Daily actives are the kings

Some big metrics we look for:
• Focus time: how much time do people spend in flow versus meetings or fighting tooling. This can get really big-brothery if you look at it individually, but it's healthy to improve on aggregate. We also surface this to each person for their own planning and scheduling.
• Daily fragmentation: how much of people's day is in usable blocks of time. problem solving (and therefore writing software) requires a bit of spin-up to be effective so short blocks aren't useful. We even suggest meeting schedules based on optimizing for the least focus-block-reduction.
• Diff Lifecycle: we measure how long diff's spend in draft, in published without review, accepted but not shipped, shipping before landing, and feedback cycles. There's no "right" timing for every diff, and it's more art than science. In general the less time code spends between publishing and landing the better everything goes. We also use this to "nag" about diffs that aren't getting review.

A few popular metrics I would suggest staying away from:
• Time spent in Draft: This ends up being a nonsense metric because everyone approaches the dev cycle differently. Some folks create diffs as placeholders before the code is written, some always publish immediately, neither one is better
• Number of diff comments (received or given): The complexity and bug rate of code doesn't correlate with the number of comments on the code reviews. There's a real bikeshedding problem with less complex diffs because people want to show contributions where some diffs that need scrutiny are often approved on trust
• Code volume/velocity: It's always better to focus on the rate that value is delivered than the speed or volume of code. Sometimes the most impactful thing a dev can do is done with very little code changed.

<@U037K9CG84A> How do you concretely actually measure focus time?

<@U037MD0907N> In our case, a big chunk of that is that all of our internal tools are instrumented and work together to give us a full picture. We (and by we I mean teams specifically targeted at productivity) can see how much time a given user spends on each of our internal tools (IDEs, Internal Web tools, Company Social media, Scheduling, VCs) and that gives up a picture that's quite clear as to how our people work. I want to be very clear that we absolutely never surface this as part of managing people, only in terms of driving aggregate increases. Goodhart's Law rules in the productivity space.

Great, thanks! For the IDE, is it being done with a plug-in for each IDE? Like, for Xcode for example, I don't know how you would measure IDE usage. 

<@U037MD0907N> I'm not intimately familiar with the technical specifics here, but our customization of the IDEs is quite deep.

Okay, that makes sense. So people are using your builds of IDEs, basically. 

:wave: What video series are you writing about?

<https://www.youtube.com/playlist?list=PLLQbIfXVLZqG0_Hg_yHLCrphP2gmhNZE1> and <https://www.youtube.com/playlist?list=PLLQbIfXVLZqHiRLgGIsFI9D5CRhhjCSAi>

<@U02162U7WCX> the next DPE Lowdown with Uber folks is going to be quite interesting, they are doing some really cool stuff
<https://gradle.com/training/devprodeng-lowdown-how-uber-does-developer-productivity-engineering/?time=1657756800>

The link in the `More upcoming events` section is correct, so I managed to register for the July 14th event :ok_hand:

Hey Niels ! For registering our Next Lowdown with Uber, <https://gradle.com/training/devprodeng-lowdown-how-uber-does-developer-productivity-engineering/|here> is the link :slightly_smiling_face:

nevermind, seems to be my internet at home

1. We do not use Gradle enterprise, we use a custom data tool and pipeline.
2. Our data tooling as agnostic to build system, IDEs, or CLI tools, so we get rich data from all of them.


Buck and Bazel Build cache are populated only in the CI infra, which is replicated in mutliple US data centers for Buck, but with Bazel we populate everywhere we have cloud region set up with remote dev servers, so they are near eng hubs.

I don't think we've produced any public content in this space yet and I haven't seen any by other companies. But let me check and get back to you. Otherwise this is good feedback for a future engineering blog or open-source project.

Are you asking about cross team/org/communities like guilds at some companies?

Yes, there are a number of tech communities, most are organic, some are explicit.

• We have explicit cross cutting groups called Ark groups consisting of very Sr engineers either relevant domain or focuses (like code quality) to provide eng wide guidance in that area.
• We have techstack specific communities for all of eng, like Android, iOS, with monthly meetups, channels, newsletters, mailing list updates, etc..
• Within orgs, they create dedicated communities, like Eats Android engineers.
• We have many self-organizing virtual teams or communities around specific projects.
• We have multiple interest based communities like gaming or music.


Thank you, this is very valuable info :pray:

Mainly how did you balance the trade-offs?

Yup this is a decision ive seen every eng org have to make at some point...

Esp when you're trying to establish compliance/auditing/guardrails

Hello everyone, @here - We are excited to announce our first Developer Productivity Engineering Summit! The event will take place in San Francisco on November 2-3, 2022. In this two-day summit we’ll focus exclusively on Developer Productivity Engineering, featuring speakers from Airbnb, DoorDash, Google, Gradle, LinkedIn, Microsoft, Netflix, Slack, Square, and Uber.

Check out the event details at the DPE Summit website &lt;&lt; <http://dpesummit.com|dpesummit.com>&gt;&gt;. Use the code *gc-slack-100* to receive a $100 discount off the registration price. See you there!

One idea we have is to maintain a central list of known flaky tests, that can be accessed and updated via API. All builds would check the list of known flaky tests and ignore those. That way a flaky test could be added to the list and instantly all builds would know about it and avoid it.

There is a gradle plugin to <https://blog.gradle.org/gradle-flaky-test-retry-plugin|retry failed tests>, which might be worth a look. We're using it successfully for integration tests.
I wouldn't use it without having some other means of identifying and fixing the problematic tests, though, but you already have that it seems.

Hi! At my company, we're using Test Retry with GE to identify flaky tests, but still let them fail the build on CI. Then developers can see PR checks failed because of a flaky test. A con is that the flakiest ones still fail a lot of builds, but at least get noticed and fixed faster (usually in proportion to how flaky they are and the chaos they might be causing :slightly_smiling_face:).

But I've been thinking about trying to catch flaky tests before they reach the main branch. Maybe running new and modified tests multiple times as part of PR checks? Wouldn't catch all types of flaky, but still. If anyone went down that road, I'd love to hear about it

<@UKWK9EVDZ> I think a way to auto-ignore tests that have recently been flaky and are still under investigation would be most helpful. I can’t promise anything yet, as far as Gradle Enterprise is concerned, but it’s definitely something we’d like to explore building as part of the product. In the meantime, assuming there’s an API to lookup a flaky test ticket for a given test, you could build a JUnit Jupiter extension based on `TestExecutionExceptionHandler` that would swallow the exception based on that condition.

<@U01LKNCQZR9> one thing that companies do is to run all new tests a specific number of times (like 100) before integrating on the main branch to ensure they are not flaky.

<@UFDR8S97S>, do you know if there's a specific tool or plugin for that?
I presume I could set it up with junit somehow. There's RepeatedTest but would have to annotate each method with it before running

Yeah that's the only one I'm aware of. Something like the `ShampooRule` also exists: <https://gist.github.com/JakeWharton/7fe7deb1f7f4a795c120>

Thanks for the feedback everyone! Much appreciated, this gives us something to go on. :pray:

<@U04CNEJC09X> we built this into Gradle Enterprise build validation scripts. One of the biggest DPE impacts that we have found is to optimize incremental builds. You essentially want to run a clean build, dont make any changes, run it again and see which tasks should have been "up to date" that were executed. you have to compare the builds.  Here are two docs. you can do it without Gradle Enterprise as well but its not as efficient/effective

<https://docs.gradle.com/enterprise/tutorials/task-inputs-comparison/>

<https://github.com/gradle/gradle-enterprise-build-validation-scripts/blob/main/Gradle.md>

Thanks to everyone who joined DPE Lowdown webcast today. thank you <@U052BD2G866> and <@U037MD0907N>. The video will be up soon. If you have any questions for Max feel free to include them here in this channel

hello, I'm trying to use gradle build toolkit in my project and facing some issues. Can someone help me out? Where can I post my query regarding the same?

hello DPE folk - FYI we’d love to see some talks about DPE at ADDO.    CFP closes in 18 hours! <https://sessionize.com/2023-all-day-devops/>

There is no page like that on <http://gradle.com|gradle.com> that I'm aware of. Their READMEs as you stated would give you the best idea of what each one does.

Is there something specific you are looking for?

Just a broad summary of what's available, but I guess the titles are also pretty descriptive.

I am curious about the Developer Champions part of the DPH framework, because it sounds like the clearest description and most connected to day to day workflow issues for your identified stereotypes (mobile, server, ML, etc.).

Is there a place where team coordination issues are discussed? Because that seems like it could me more a characteristic of a team (which might have a cross-functional membership) than of a persona.

Code reviewer response time (one of your chosen metrics) led me to do a motivational cartoon advocating for synchronous paired review to avoid long cycling. Smaller, more frequent code increments is another approach to avoid stalling and merge trouble.

What do you mean by team coordination issues?

I’ve heard a lot of people advocate for paired review. I’ve never seen it function in a large engineering org. It definitely stops working once you have major time zone barriers. I hear lots of people say positive things about it, though. 

Stalling on other teams, rework because of changed integration terms, choke points in flow, demands from security or compliance showing up at awkward times. Or maybe you're part of a customer integration team waiting for a bug fix or schema change. In this case the persona might be similar on a happy workflow day but pain points differ.

Well, that’s just organizational coordination. The only thing special about that for any team is how many interdependencies they have. It’s not so much a persona as an aspect of a project. There’s no special process for it that we own as the Dev Prod team. 

In some sense none of these are tooling issues, but bad tooling can make coordination more difficult.

I could imagine bad and good ways to do it, but I would basically just be sharing my opinion, not anything empirically validated. :)

OK, so the DPH framework mostly addresses unblocked workflow.

I think if we discovered alignment was a major issue specifically for some persona, we would try to surface that too. 

Thank you for the clarification. Good tooling and in-team workflow is important, but at some point developer productivity and happiness hits Conway's Law issues (Team Topologies), and knowledge transfer, and those have been most salient to me.

But it would surface by being a pain point we discovered in the survey. If we saw it for multiple personas, we might try to address it in a broader way, across the org. I personally go to all the persona reviews, so I can deal with issues that appear in multiple places. 

Sure, I think the most important productivity issues usually lie outside of tools and infrastructure. 

The catch is how well your survey instrument is designed to catch those things. 

DPH sounds like a good place to start with providing each team member what they need.

Yeah. I mean, conceptually everything you’re talking about should show up in our Happiness signals. I would like to improve our survey so that it does a better job there. I have seen some in-person interviews done internally that did raise issues like this. 

And the Champions are less about team coordination?

Yeah, they are more about being advocates for the personas. 

More the surveys as sources for themes there.

The Champions do do all the survey analysis. 

I hear a little echo of Netflix's "guilds" notion as dispersed roles with similar interests and issues.

Could be! I actually haven’t read about Netflix’s thing. 

I think NF's are self-organizing knowledge transfer and solutions providing groups around particular technical interest areas. Narrower than personas, probably, but sharing the notion of common concerns across teams.

I'm happy that you get to share your work here. Thank you again.

Ah, I get it about Netflix’s. My suspicion is that that sounds better than it is in reality. :laughing: 

set the channel topic: Anything about Developer Productivity Engineering: best practices, tools, automation.

My presentation on Release Drafter - a changelog automation tool and GitHub Action we use in some Gradle projects, and in other communities like Jenkins and WireMock. If any of Gradle maintainers are interested, happy to work together on a shared template for Gradle plugins! <https://speakerdeck.com/onenashev/automate-your-changelogs-release-drafter>

A quick question, to which I didn't find the answer on the slides, nor in README.md (quick skim), how does this compare to <https://docs.github.com/en/repositories/releasing-projects-on-github/automatically-generated-release-notes|GitHub's build-in support> for the same thing? What's the rationale? (The closest answer was probably the xkcd 927 slide.) [I guess historically this existed first?]

Good question. GitHub actually adapted one of the initial concepts to have a very simple generation on its side. IIRC the first prototype has even used the release drafter code :)

Ky differences, unless new features were added to GitHub:
• No support for label categorization
• No automatic release draft generation, just on-demand one
• No String replacement
• No implicit auto-labeling when no label is missing
• No support for skipping a pull request

Nice, makes sense. Feels like this should be in the readme for users to make an informed decision whether to use built-in or release-drafter.

Re automatic: `gh release create 1.0.0 --draft --generate-notes` (see <https://cli.github.com/manual/gh_release_create|gh docs>) on `push: branches: main` will do the job.

Indeed, such automation works and can be added to your Pipeline.
For projects without continuous delivery, personally I prefer having the GitHub release as a pipeline trigger though

1. Integrate things
2. Open GitHub Releases and the changelog draft by the release drafter
3. Copy-edit the changelog
4. Click "Publish Release"
Obviously, it works if and only if your release pipeline is fast
Example - <https://github.com/wiremock/wiremock-testcontainers-java/blob/main/.github/workflows/release.yml>