Live data from Hacker News

1,145 pull requests per day

saile.it

31–40 of 91 posts

Re: 1,145 pull requests per day

#33
It is undoubtedly very impressive. But once you're set up for it, it's probably easier than saving up the changes and doing a big release at the end of the month, because the amount of change and the amount of risk, per deployment, then is also a lot higher.

Like other commenters here have said, it doesn't mean that I can say "(scoff --) we're doing the same" if I'm doing the same relative number of releases with my tiny team. But it is validating for a small team like mine to see that this approach works at large scale, as it does for us.

Re: 1,145 pull requests per day

#34

Diminishing returns at some point, but, I think the counterpoint to this is companies who are doing a single huge manual deployment every month (or less) which is scheduled into a 4-hour outage window where many if not all services will be down for this period. I do agree there isn't a lot of delta between a company doing 2 or 10 deploys a day and a company doing 1,200, but, there's a huge engineering gap between com…

Open source projects can be the worst at this stuff. I realise it's all volunteer run so I'm not complaining too much. But so often they end up pushing a versioned release once a year. So you end up finding a bug, going to report it and see it was fixed 8 months ago but still broken in the published package. And then they get afraid to push a new version because it's been so long since the last one that everything has changed.

Re: 1,145 pull requests per day

#36
post #13

Is counting the number of pull requests a useful measure of engineering performance ergo product performance and company perf? Isn't it more like a BS counter that keep incrementing and that is indicative of churn but nothing else reliably. One of the most low effort, easily to game metric that can be skewed to show anything that the user wants to show.

In my org they count both the number of pull requests, and the number of comments you add to reviews. Easily gamed, but that's the performance metric they use to compare every engineer now.

I’m going to write myself a new mini van this afternoon

Re: 1,145 pull requests per day

#37

Is counting the number of pull requests a useful measure of engineering performance ergo product performance and company perf? Isn't it more like a BS counter that keep incrementing and that is indicative of churn but nothing else reliably. One of the most low effort, easily to game metric that can be skewed to show anything that the user wants to show.

By itself not, but combined with the rest of DORA metrics it's a pretty good indicator.

Re: 1,145 pull requests per day

#38

It is undoubtedly very impressive. But once you're set up for it, it's probably easier than saving up the changes and doing a big release at the end of the month, because the amount of change and the amount of risk, per deployment, then is also a lot higher. Like other commenters here have said, it doesn't mean that I can say "(scoff --) we're doing the same" if I'm doing the same relative number of releases with my…

Yeah I get itchy if the pipeline to prod ain't working for more than 24h for one microservice. I love continuous deployment.

Re: 1,145 pull requests per day

#39

Why do they need to change their software that much that often?

Not every PR is a feature. There will be lots of laying groundwork. Stuff going in but not yet activated as a feature flag. Small changes often make roll back easier. Regressions easier to detect. You can blue green your little change and auto detect if it is causing latency or availability issues on 1% then 10% etc. of traffic. This means you can early detect and do easy roll backs as nothing much has changed.

Downside: your code is always a Frankenstein monster of feature flags that need to be cleared up! But hey that's more PRs to boast about.

Re: 1,145 pull requests per day

#40

Why do they need to change their software that much that often?

It completely depends on what they call "a change", and the article does not make that clear.

If they're doing some sort of strict continuous integration, then, a "change" could be a 25 lines function with a 100 lines of unit tests, in the frame of a large project where the function will be used later in a UI component that will only be merged in two weeks.

The fact that it's "deployed" does not mean it's "used" in production as a final thing ; it might very much be "a step in the development".

And, even if they're shipping "feature" (that is, they're deploying the last commit in a project), it does not mean that all millions of users are seeing the change (they could use feature toggles, A/B testing, etc...)

Seen this way, about 2 PRs per day per eng is not unreasonable, and with enough devs, you can reach it.

Finally, they might very well have some automated PRs (i18n, etc..)

Post reply on HN