It's git push origin branch and then merge after submitting a pull request from branch to main after a successful lint check, build, deployment, and testing in a non-production environment, and PR approval. What kind of wild west operation allows pushing directly to main?

[–] Michal@programming.dev 45 points 8 months ago

👆 This guy gits it

[–] redcalcium@lemmy.institute 39 points 8 months ago

Employees who push first win and get to leave early. The rest would be the suckers who would merge whatever mess left behind by the early employees.

[–] fckreddit@lemmy.ml 35 points 8 months ago (1 children)

Single person operation pushes directly to main.

[–] Pacmanlives@lemmy.world 5 points 8 months ago* (last edited 8 months ago)

Hey there were like 3 of us lol! No joke that’s what I have done at a few of the smaller shops as an SRE/System Engineer

[–] dan@upvote.au 10 points 8 months ago* (last edited 8 months ago) (1 children)

Our changes land in main at my workplace, once they've received a code review and all CI checks pass (which includes tests, E2E tests, etc). We use feature flags rather than feature branches, so all diffs / pull requests are against main. We use continuous deployment which means changes are automatically deployed once landed. Changes roll out just to employees, then to servers used by a small percentage of users (2% I think), then everywhere. All risky changes are gated by feature flags so they can be enabled or disabled without a code push.

[–] nilloc@discuss.tchncs.de 3 points 8 months ago

We did a similar way with tag based releases, first a test tag, the production tag when signed off.

[–] MR_GABARISE@lemmy.world 9 points 8 months ago (1 children)

What kind of wild west operation allows pushing directly to main?

That's kinda the whole point of trunk-based development.

[–] aport@programming.dev 2 points 8 months ago

Lol no it is not

[–] AA5B@lemmy.world 6 points 8 months ago

No kidding. Never push to main, and you most likely can’t. While I get the joke of the meme, I’d send the person packing if they don’t understand branching, and branch flow, rebasing or reverting. Even if you look up the command or do it all through your IDE, understanding the workflow of using git is important

[–] SpaceCowboy@lemmy.ca 4 points 8 months ago (1 children)

They laid off everyone else so there's no one to the code reviews now. So fuck it, we'll do it live!

[–] AA5B@lemmy.world 3 points 8 months ago* (last edited 8 months ago)

We just had a customer escalation caused by exactly this. One group relied too heavily on tribal knowledge for code reviews and didn’t want any other process. Once the tribal elders were gone, no one knew all the things to look for, and there was no other way to catch issues

As a Continuous Integration and Test guy, I was standing in the corner yelling “I thought you were DevOps. Where’s the automation?” Fine, Puppet/YAML doesn’t work with a traditional build and test, but you could have done syntax validation and schema validation that would have caught before the code review could have happened (and I showed them how a year ago, even offered to do it for them) and set up some monitoring to discover when you break stuff, before customers discover it.

[–] korok@possumpat.io 2 points 8 months ago (2 children)

Do you not use a fork as your origin, separate from the production upstream repo? I’ll push to my fork’s main branch for small or urgent changes that will definitely be merged before anything else I’m working on.

[–] Solemn@lemmy.dbzer0.com 1 points 8 months ago

If it's a private repo I don't worry too much about forking. Ideally branches should be getting cleaned up as they get merged anyway. I don't see a great advantage in every developer having a fork rather than just having feature/bug branches that PR for merging to main, and honestly it makes it a bit painful to cherry-pick patches from other dev branches.

[–] 1984@lemmy.today 2 points 8 months ago (1 children)

I never worked anywhere where they had this set up. I would push to branches and make pull requests, but always work in the production environment.

I was mainly working as a data engineer though so that's probably why. It's hard to have test environments since you can't replicate all the enormous amounts of data between environments without huge costs.

[–] expr@programming.dev 3 points 8 months ago (1 children)

There are many strategies for maintaining test environments for that kind of thing. Read-only replicas, sampling datasets for smaller replicas, etc. Plenty of organizations do it, so it's not really an excuse, imo.

[–] 1984@lemmy.today 2 points 8 months ago* (last edited 8 months ago)

No I know. But it was "good enough" for the company and we never had any serious issues working that way either. If someone pushed a faulty commit, we just reverted it and reloaded the data from the source system.

A lot of companies have kind of bad solutions for this sort of stuff, but it's not talked about and nobody is proud of it. But it keeps the environments simple to work with.

[–] Pacmanlives@lemmy.world 1 points 8 months ago* (last edited 8 months ago) (1 children)

You kids with your fancy branch support back in my day we had CVS and RCS liked it

https://en.m.wikipedia.org/wiki/Revision_Control_System

[–] Nalivai@discuss.tchncs.de 1 points 8 months ago

You mean "I just sent you zip file with my new changes via email, get fucked looser"?