3 ms·

me either, so now anecdata of 2; but also, sounds insane of all the things a human should be in the loop for, merging to main seems like one of them

by veidr 3y ago

veidr 3y ago
(also nuking from orbit)
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.
staindk 3y ago
If main/master isn't your production branch then allowing auto merge makes a lot of sense. And if your changes have been QA'd in staging and/or they aren't that hectic (and are backwards compatible) then I think auto merge into prod can be fine too.
- veidr 3y ago
  Yeah; I was assuming main is the production branch. I basically do not think "auto merge into prod" is ever OK, but then again, I let GitHub Copilot write 40-60% of my doc comments, so...
  - capableweb 3y ago
    > I basically do not think "auto merge into prod" is ever OK, but then again, I let GitHub Copilot write 40-60% of my doc comments, so... Funny how different people can be :) I'll always try to make the main branch so clean that it can be deployed at any moment, and production will always use the latest commit as soon as possible. Basically, I'm doing CI + CD, but I understand it's not for everyone.

me either, so now anecdata of 2; but also, sounds insane of all the things a human should be in the loop for, merging to main seems like one of them

by veidr 3y ago

me either, so now anecdata of 2; but also, sounds insane of all the things a human should be in the loop for, merging to main seems like one of them

veidr 3y ago

(also nuking from orbit)

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.

staindk 3y ago

If main/master isn't your production branch then allowing auto merge makes a lot of sense. And if your changes have been QA'd in staging and/or they aren't that hectic (and are backwards compatible) then I think auto merge into prod can be fine too.

veidr 3y ago
Yeah; I was assuming main is the production branch. I basically do not think "auto merge into prod" is ever OK, but then again, I let GitHub Copilot write 40-60% of my doc comments, so...
- capableweb 3y ago
  > I basically do not think "auto merge into prod" is ever OK, but then again, I let GitHub Copilot write 40-60% of my doc comments, so... Funny how different people can be :) I'll always try to make the main branch so clean that it can be deployed at any moment, and production will always use the latest commit as soon as possible. Basically, I'm doing CI + CD, but I understand it's not for everyone.