Amateur. You want real performance? Code in prod. Literally could not be better for collaboration to have the whole team working directly from production servers. Best part? You get INSTANT feedback.
My old boss (at a sturtup with some ten ppl) loved to do this. When you’re done with your work, merge to master. Boss-man would then revert the commits if he didn’t like the result. Since the branches all were merged, no-one knew what was actually in prod. Fun times.
If somebody actually did that it would be grounds for removing their privileges to merge into master. THIS, THIS is why the JavaScript ecosystem has gotten so bad, people with mentalities similar to his.
Before everyone loses their minds, in Extreme Programming there are safeguards other than PR reviews. Before you submit a PR, you are supposed to have written the tests and to have written your code with pair programming, so your code already has some safety measures in place. On top of that, when you merge and deploy, more tests are run, and only if all of them are green do your changes go into production.
Nothing improves morale like the on-call having to unfuck production for the third time that hour because mUh VeLoCiTy decided code review and testing in CI was too slow.
Kinda acceptable if you have a slow release cadence. Everything needs to be reviewed and fixed/accepted (with defect/US raised) before production though.
Needs to be in a smaller team with decent Devs too though!
It’s insane to me that gitflow won over TBD and Continuous Integration to the point that this is now considered an extreme position. Not all projects are open source with many remote collaborators.
Am not sure I disagree but I don't agree completely. It's insane to merge things that go to production without testing. However at the same time I don't like continuous integration one bit. Open source mantra is great in my opinion. Release early, release often. If code chews some important data, have a test version of it that needs to run some time before it gets pushed to production.
Delaying merge of someone's code means branches get further and further apart. At the same time code in main branch gets fixed and tested the most. I would merge often but only full features. None of the half-done stuff. Let humans test it a bit before it reaches target audience. That is usually good enough to catch most bugs. Those that do happen to leak into production are easily fixed since you have fast development cycle and deployment pipeline. And backup frequently.
I kind of with the sentiment. Review pre merge though, but only block the merge if there are serious faults. Otherwise, merge the code and have the author address issues after the merge. Get the value to production
Probably unpopular opinion, but peer reviews are overrated. If coders are good AND know the project, the only thing you can do in a PR is nitpicking. They are more useful for open source collaborators because you want to double-check their code fits with the current architecture.
But people here are reacting as if peer reviews could actually spot bugs that tests can't catch. That happens rarely unless the contributor is junion/not good.
That's nice but it goes against our quality standards and the international quality standards we are charging the client extra for adhering to, the line you're trying to merge into is stability and needs CCB approval for the merge, and the client has specifically requested only showstopper-level bugs be addressed for stability lines. You know what, I have neither the time nor the crayons to properly explain this to you, a consultant that supposedly knows the business. Pack your shit, you're gonna have a wonderful time posting this crap on LinkedIn instead. #gitshiton