It is too much friction for a “small” inhouse team imo
Conversation
Replying to
I think it depends on the kind of project.
If something goes into production quickly based on what gets merged, that's different than having a release cycle where there's time to stabilize things before an actual release.
1
4
At least once you have more than a couple people it's really inconvenient / horrible for the main development branch to be broken. I can see it not working well if there isn't a culture of quickly reviewing things for people and a very well made bot that quickly tests + merges.
1
Replying to
I’ve worked on branches with hundreds of in house devs, it is possible to run a high trust fast revert model with a lot of people
1
2
Replying to
A high trust model could mean people can sign off on their own change and the bot tests + merges it the same as always though. Take a look at how Rust merges changes if you haven't.
2
Replying to
Open source is low trust and therefore needs a lot of gatekeeping that you don’t need for the person sitting next to you.
1
6
19
Replying to
I'd happily push a change to refs/for/master instead of to master and have CI quickly build + test and merge it for me even for projects where I'm the only person working on it. I don't do it because the tooling on GitHub is horrible.
1
2
So, basically, what I'm used to for collaborative projects with good bots + CI is that committers can approve their own change, but regardless, the bot is going to test + merge it. Especially important if you target a bunch of platforms people can't just test locally easily.
1
2
Even if just target 1 platform and the development testing environment is nearly exactly the same as production, which generally isn't the case, it's really useful to have the changes run through a build + test and merged automatically so you actually can't break the main branch.
1
2
The pain it requires is relative to build time. If build time is 1 minute, there's really no pain involved in that kind of system. There's the honor system of people approving their own changes for simple / obvious stuff but someone else doing it for more complex stuff basically.
1
2
The tooling needs to be really good though. I have a lot of problems with GitHub CI. If the builds are really long, it also starts getting increasingly annoying especially in combination with a fast moving project with many contributors. Need really good infrastructure for it.
GitHub workflow + UI + their CI is all around really bad / unreliable. I would happily pay $150 / month for GitHub if they actually gave me a really good UI and powerful CI infrastructure that worked really well. I wouldn't trust them to actually ever provide that though...
1
2
Just haven't had a good experience with those platforms / companies. It makes me dislike CI because their CI is so ridiculously bad. Same for code review. I don't exactly think Gerrit is an amazing UI for it's an order of magnitude better workflow + review UI than GitHub.
1
1
Show replies