3 ms·

This is a real problem in my current place (huge monorepo, 100+ devs, 100+ merges per day). Like others said, "merge queue" is the solution. GitHub's one has b

This is a real problem in my current place (huge monorepo, 100+ devs, 100+ merges per day). Like others said, "merge queue" is the solution. GitHub's one has been in beta for many months now. There are also dedicated companies doing this like https://mergify.com/ https://mergify.com/ But there's several tricky aspects like "what if I want some commit to jump in front of queue?", compliance etc. Due to the multitude of requirements and off-the-shelf solutions being somehow limited, infra folks in my place are considering building a custom solution :)

jd__ 5y ago
I'd be curious to know what you find limited in off-the-shelf solutions? (disclaimer: I'm from the Mergify team )
- lhorie 5y ago
  One question and one comment. Question: You list Uber (my employer) as a user in your homepage, but searching internally, the only search result for mergify is a mergify.yml in some random debian module for lua, so it doesn't seem like we actually use it for anything (and we built an in-house solution for the repos w/ serious commit traffic). I'm curious how you determine who your corporate users are? Comment: we ended up building a merge queue in house because frankly build/test pipelines can look very different,(e.g. at one point we had jenkins pipelines and buildkite pipelines, some using bazel, some not, talking to phabricator instead of github, etc). At the end of day plugging in a merge queue technology requires a bunch of work integrating with a myriad of things anyways. Since the engineering effort is relatively high regardless, doing it in house lets us experiment with more aggressive optimization heuristics than just waiting on a 3rd party.
  - jd__ 5y ago
    We know Uber has some great internal tooling (there's even a paper published on their merge queue: https://eng.uber.com/research/keeping-master-green-at-scale/ https://eng.uber.com/research/keeping-master-green-at-scale/). We had various Uber engineers using Mergify on open source repositories those last years. I didn't check recently if that was still the case, I'll make sure our lis is not too much outdated. I definitely agree with your view on how pipelines can be different. I think none of our customers has something that is exactly the same. However, many of them don't have the workforce to build in house or even to optimize as far as you would do in a (very) large company.
    - lhorie 5y ago
      Ah, good point, our internal search tool only indexes internal code, so that makes sense, thanks!

jd__ 5y ago

I'd be curious to know what you find limited in off-the-shelf solutions? (disclaimer: I'm from the Mergify team )

lhorie 5y ago
One question and one comment. Question: You list Uber (my employer) as a user in your homepage, but searching internally, the only search result for mergify is a mergify.yml in some random debian module for lua, so it doesn't seem like we actually use it for anything (and we built an in-house solution for the repos w/ serious commit traffic). I'm curious how you determine who your corporate users are? Comment: we ended up building a merge queue in house because frankly build/test pipelines can look very different,(e.g. at one point we had jenkins pipelines and buildkite pipelines, some using bazel, some not, talking to phabricator instead of github, etc). At the end of day plugging in a merge queue technology requires a bunch of work integrating with a myriad of things anyways. Since the engineering effort is relatively high regardless, doing it in house lets us experiment with more aggressive optimization heuristics than just waiting on a 3rd party.
- jd__ 5y ago
  We know Uber has some great internal tooling (there's even a paper published on their merge queue: https://eng.uber.com/research/keeping-master-green-at-scale/ https://eng.uber.com/research/keeping-master-green-at-scale/). We had various Uber engineers using Mergify on open source repositories those last years. I didn't check recently if that was still the case, I'll make sure our lis is not too much outdated. I definitely agree with your view on how pipelines can be different. I think none of our customers has something that is exactly the same. However, many of them don't have the workforce to build in house or even to optimize as far as you would do in a (very) large company.
  - lhorie 5y ago
    Ah, good point, our internal search tool only indexes internal code, so that makes sense, thanks!