I checked whether well-known dev tools companies actually require code review before merging to main. Most don't (codatus.com)
from peternovakdev@programming.dev to programming@programming.dev on 30 May 09:19
https://programming.dev/post/51204155

I scanned the public repos of 128 YC-backed dev tools companies, 6,195 repos in total. I expected the companies building our tooling to enforce the basics on themselves. Only 2 of the 128 require any status check to pass before merging.

#programming

threaded - newest

CrypticCoffee@lemmy.ml on 30 May 09:42 next collapse

Startups hack things in to production?

Shocked, I tell you.

peternovakdev@programming.dev on 30 May 09:55 collapse

Right? The part that surprised me was that most of them turn branch protection ON and then don’t require any check to pass. So the gate is there, it just doesn’t gate anything. Makes me wonder if private repos are the same or if the public ones just get less attention.

dwt@feddit.org on 30 May 10:02 collapse

Not a start up, but we require code review, even though it is not enforced via rules, to allow emergency overrides.

Gets used maybe once every 300 pull requests though.

Convention over configuration is a thing - so maybe look into their actual merge behavior?

peternovakdev@programming.dev on 30 May 10:19 next collapse

Good distinction. If it’s useful, GitHub lets you require checks and still grant a bypass for specific people or teams, so the hard rule and the emergency escape hatch can coexist, and the scan reads that as passing. Could be you’ve already weighed that, in which case ignore me.

VonReposti@feddit.dk on 30 May 10:22 collapse

My old workplace had the same’ish. The developer team who owned the service had rights to disable branch protection. Disabling this would create alerts to the manager but allowed an on-call developer to make an emergency bug fix at 2am and get a postmortem review the next day.

setsubyou@lemmy.world on 30 May 11:04 next collapse

We used to use completely separate tools for code review (in our case because the process was older than git). Some of them might be doing something similar.

atzanteol@sh.itjust.works on 30 May 12:33 next collapse

This was my first thought - just because your code is on GitHub doesn’t mean you’re using it for everything.

peternovakdev@programming.dev on 30 May 17:05 collapse

That’s fair, and it’s a real limit of measuring GitHub config. If a team runs review or merge gating in a separate tool, or mirrors to GitHub from somewhere that’s their actual source of truth, the scan won’t see it and they’d look unprotected when they aren’t. The finding is really about repos where GitHub is the place the work happens, and even then it’s public repos only. Worth saying plainly so the number isn’t read as more than it is.

MalReynolds@slrpnk.net on 30 May 14:25 collapse

Why would you do that?

Because you hate yourself?

Oh, right, you found a tool (self reflect) that let’s you do it with zero effort. FU…