3 ms·
> of all the things a human should be in the loop for, merging to main seems like one of them That's what the review is for. And I'd argue that the review shou
by capableweb 3y ago
> of all the things a human should be in the loop for, merging to main seems like one of them
That's what the review is for. And I'd argue that the review should be decoupled from CI, because you're not reviewing if you think the tests is passing before/after merge, you're reviewing the code and docs themselves.
And once the review is done, it should be fine to merge at any point, today or tomorrow, barring any merge conflicts of course.
Merging to main should be the most mundane task ever, and even a robot should be able to do it with confidence.
- 000ooo000 3y ago>once the review is done, it should be fine to merge at any point, today or tomorrow Sometimes there are considerations like QA/infrastructure resourcing that dictate when something can go into master. Ideally that's rare but I have worked in a place where it's a consideration for every single merge. To expand on this a little: we had a simple branching model. To/from master for work, branch from master to cut a release. Being highly regulated, as a matter of (unchangeable) policy, every change needed testing by QA team. QA team == QA guy. Among feature work without hard release dates, there was also bug fixes with some urgency, and regulatory work with hard release dates. Given we traded flexibility in our branching model for simplicity, we instead had to consider if something could be merged to master without impacting QA load of anything already merged but not released. It worked fine for us but were were a team of <5. My remark about trading flexibility is really the crux of it all though. There's compromises that need to made and this one made sense for us at the time.