[HN Gopher] Launch HN: MergeQueue (YC S21) - Automate rebasing a...
___________________________________________________________________
Launch HN: MergeQueue (YC S21) - Automate rebasing and merging for
your codebase
Hi HN, we're Spriha and Ankit, founders of MergeQueue
(https://mergequeue.com/). We enable automatic merges for your
Github Pull Requests, based on configurable rules you can set for
each repo. These automated merges ensure you never have failing
builds on master/main and save time on rebasing your feature
branches. If you have a monorepo where a big engineering team is
regularly merging changes, the stability of the main branch
degrades considerably. This happens because more engineers working
on the same codebase introduce incompatible changes, causing builds
to break even though their commits pass independently. Here's an
example: https://blog.mergequeue.com/managing-github-merges-for-
high-.... Github has a setting to restrict branches to be up to
date before merging, but turning on that setting ends up forcing a
rebase-athon within the team. This results in wasted time, and all
too often, a stressful scramble to figure out what changes broke
the build. We had this problem in our previous company where we
looked for a solution to automate the process. We found this paper
[1] published by Uber to manage monorepos at scale and we built a
lightweight version of that internally. It immediately eliminated
the overhead of keeping builds healthy. After that, we decided to
build a public version to save others from re-inventing the wheel.
We spoke to engineers at Airbnb, Stripe, Uber, Shopify, Quora and
other large companies who have internally built similar tools, but
teams who need such tools the most often don't have the bandwidth
to dedicate developers to building and maintaining them.
MergeQueue (MQ) is a FIFO queue of Pull Requests (PRs) that works
as a Github app. To use MQ as a developer, instead of merging
manually, you just add a Github Label "mergequeue" to the PR. MQ
then takes care of the rest: it sequentially updates or rebases the
branch, monitors the configured CI checks and eventually merges the
changes. If the checks fail, it will dequeue the PR, add comments
describing the reason and move to the next one. For high output
teams, MQ also offers batch mode to run CI in parallel batches. If
you'd like to learn more, there's a lot more here:
https://mergequeue.com/documentation. Currently, we are also
piloting a way to manage "flaky" (i.e. unreliable) tests through
MQ. This integrates with your CI provider (we currently support
CircleCI), analyses test results and flags the tests that fail
inconsistently. When flaky tests are identified, MQ reruns the test
depending on the configuration set. We charge by usage in an
organization, so for instance if your organization has 100
developers but only 20 of them use MQ, only those 20 will be
billed. You can sign up for a free 14 day trial without a credit
card. We also support single tenant or on-prem deployments, have
webhooks to connect to your other apps, offer multi-queue support,
and are SOC2 certified! We'd love for you to try MergeQueue and
give us any feedback you have. If you've used something similar in
the past, we're also curious to learn what problems you faced so
we're better prepared for them ourselves :) [1]
https://eng.uber.com/research/keeping-master-green-at-scale/ -
discussed at the time: _Keeping master green at scale_ -
https://news.ycombinator.com/item?id=19692820 - April 2019 (115
comments)
Author : spriha
Score : 75 points
Date : 2021-07-16 16:32 UTC (6 hours ago)
| h3mb3 wrote:
| How does this compare to Bors NG?
|
| https://github.com/bors-ng/bors-ng
| rokob wrote:
| This was my question too. I considered making a company out of
| Bors but didn't think it would work because Bors mostly just
| works.
| spriha wrote:
| Haha yeah we're that company- turns out there's actually a
| lot to do, especially when handling this at scale! come join
| us :)
| spriha wrote:
| bors solves a similar problem, but we've found that enterprises
| require a lot of additional features to get their dev teams to
| actually use it, so we've focused on those to make this
| production-ready. Specifically:
|
| 1. We focus on being "no-maintenance", since our primary value
| prop to customers is "you won't have to spend eng resources on
| merge problems any more". This means: a one-click "set and
| forget" install, no additional config files to maintain or DSL
| to learn, unlike bors.
|
| 2. We have all the security and access-control features you'd
| want (we're Soc2 compliant, offer on-prem etc). This is
| important since the product interacts with our customers'
| source code.
|
| 3. We offer various customizations on merge workflows to help
| our customers optimize the exact parameters they care about
| (eg: developer wait time vs CI costs vs time to identity bad
| PRs in a batch, optimistic merge heuristics etc)
|
| 4. We offer a whole host of useful analytics to show you merge
| bottlenecks. We initially just put these as a nice-to-have, but
| we've now got customers who use us specifically because of
| these analytics!
|
| We're also constantly adding new features based on customer
| requests (for instance, the flaky test features we're piloting
| originally came from customer requests we kept hearing over and
| over!). Speaking of which, if there's something you'd like to
| see that you don't currently get from your existing
| system/bors, do let me know :)
| timtamboy63 wrote:
| MergeQueue is phenomenal. We've been using it for a few months
| now and it's been great for keeping PRs green and helping merge
| quickly.
| ankitdce wrote:
| Thanks @timtamboy63, now we know you you are :)
| oauea wrote:
| Why is the pricing per collaborator?
| ankitdce wrote:
| Thanks for asking! We priced it to ensure that it's affordable
| for small teams and is only charging based on who uses it for
| larger teams. Would you have preferred a different plan.
| spriha wrote:
| tbh we've found it's just easier for many of our customers that
| way. However, we do offer custom pricing plans (annual
| contracts etc), so do let us know if you have a different
| preference!
| jeremyis wrote:
| A previous employer that underwent a massive multi-billon dollar
| migration to SOA (and then folks went too far and made everything
| a micro-service so had to rollup some work) basically because
| merging became too slow into our monorail as we got to ~O(1k)
| engineers. We had an in-house solution like this that we used for
| 2-3 years (and a worse version for years before that). What a
| great idea to productive it!
|
| IMO the SOA migration simply due to merging was such a heavy-
| handed solution. If we could have made our MergeQueue way better,
| perhaps we could have avoided that multi-billion dollar (+ the
| rollback work) fiasco.
|
| Congrats!
| ankitdce wrote:
| Wow, that's a great story, maybe we should quote that :) If you
| are open to sharing more of that experience, I would love to
| hear that. You can also directly email me at
| ankit[at]mergequeue[dot]com if you don't want to post publicly.
| deshraj wrote:
| Congratulations on the launch. Great idea and definitely agree
| that this is a problem at a lot of companies.
|
| Although I am curious about if there is enough market for this
| product. Would love to hear back any market research you guys
| have done before. Thanks! :)
| oracle2025 wrote:
| Can say from my professional experience, that this is definitely
| a problem worth solving.
| ankitdce wrote:
| <3 curious where have you experience this the most? We are also
| trying to figure out at what point does the problem become
| acute.
| programmarchy wrote:
| Here's one. I currently have about five or six small PRs open
| for bug fixes and minor features. However, they've languished
| a bit in review and haven't been merged yet. In the meantime,
| I've started a fairly significant refactor. It's not too
| complicated but involves moving files and changing some core
| structures. I am dreading having to rebase those open PRs!
| ankitdce wrote:
| Interesting, you can potentially use MQ for automatic
| rebasing as well, but if there is a merge conflict, MQ will
| not be able to resolve it for you. If a rebase can be
| automatically resolved, then MQ will update the branch for
| you.
| sdesol wrote:
| I'm not your competitor, but I am trying to make software metrics
| a good thing for everybody (developers and leaders) and I'm not
| sure you can make a claim like the following on your landing
| page: "Know your star developers."
|
| with the limited analytics that you can gather from a pull
| request.
| spriha wrote:
| Fair point! We definitely don't want our analytics to be used
| to enforce/incentivize arbitrary targets (we've seen those
| behaviors backfire so many times, unfortunately...). I'll
| update the language from "Keep a tab on your builds and merges.
| Know your star developers" to "Keep tabs on your builds, merges
| and developer activity".
| epage wrote:
| Excited to see more stuff in this space. I've previously done
| some investigation into the various options [0]
|
| Questions:
|
| - Why have your own pre-conditions rather than relying on
| Github's built-in conditions and Status?
|
| Ideas
|
| - Autosquash fixup commits. I like to have multi-commit PRs that
| get merged into main. I'd like to leave my fixup commits up to
| make it easier for reviewers to see fixes and then have the tool
| doing the merge fix them up for me rather than doing yet another
| CI run for the fixups
|
| - What about AzDO's semi-linear rebase option? This rebases a
| branch and then creates a merge-commit, keeping history linear
|
| [0] https://epage.github.io/dev/submit-queue/
| polskibus wrote:
| How does it compare to GitLab's merge train feature?
| ankitdce wrote:
| Yes it's somewhat similar to GitLab merge train. Of course we
| work with Github. And similar to other comments, there are a
| few more features including batch mode and flaky test
| management that make MQ a more interesting offering. We do not
| support Gitlab today.
| parthi wrote:
| Will give it a try!
| spriha wrote:
| <3 Let us know what you think!
| eatonphil wrote:
| Really dumb question while I'm trying to decide whether to use
| something like git vs. CRDTs to handle version control for user
| changes made in an app I'm working on: why do we even use git
| anymore for source code version control if we want behavior like
| this?
|
| Nobody likes merge conflicts. We all want versioning. So long as
| we have versions at all why isn't the ideal interface for
| developing in teams something more like editing in Google docs?
| Why aren't we just doing that? Why are we still using systems
| that produce merge conflicts?
|
| Hoping for insight from folks who have either done this
| themselves or looked into it.
|
| Edit: one particularly nice feature of Google docs over
| Confluence is that in Google docs I can suggest changes that is
| somewhat akin to branches with git. I don't need to force my
| change through without review. This isn't a natural part of
| CRDTs, but it sounds like the nicest source control system might
| be CRDTs plus branches?
| awestroke wrote:
| Because you'd never have a working revision to release, since
| everyone on the team will not finish their features at the same
| time.
| lifekaizen wrote:
| It's a good question. Well, CRDTs are just an underlying data
| type that guarantee conflict free eventual consistency. That
| doesn't mean the result would be an English paragraph or
| buildable code, however. Then what git does really well that
| bare CRDTs don't are things like branching and local
| experimentation. Being intentional with commit points can also
| keep file sizes down, for a more real-time tool like Docs
| potentially every character change would be stored. CRDTs can
| have performance problems with things like file size growth.
|
| For, your use case of user changes, CRDTs seem like a good
| option. It would be interesting to explore building a version
| control system on top of CRDTs, if done right it could have the
| benefits of git with less merge conflicts.
| oftenwrong wrote:
| For user changes, a solution based on OT/CRDT may be
| appropriate.
|
| For code, you need merge conflicts. Let me put it like this: Do
| concurrent edits in google docs always produce a valid and
| correct paragraph, with no grammatical errors, and that
| communicates the proper thoughts?
| eatonphil wrote:
| If we need merge conflicts that must be manually resolved,
| how can this product being discussed exist?
|
| If merge conflicts can be automatically resolved, why aren't
| we using a system that does operates like that under the hood
| rather than needing a product like this bolted on?
| oftenwrong wrote:
| There are ways to resolve merge conflicts automatically in
| some cases given some assumptions, but there is no way to
| resolve any given merge conflict without a system that can
| create a correct program. I won't bore you with the formal
| proof for this (especially since I have no idea how to
| construct such a proof). Consider that some merge conflicts
| require new code to be written to resolve them.
|
| For example, here's an original program:
| if(foo()) { send_money_to_oftenwrong() }
|
| and here's a change we would like to merge:
| if(bar()) { send_money_to_oftenwrong() }
|
| and here's a concurrent change we would like to merge:
| if(baz()) { send_money_to_oftenwrong() }
|
| How do you produce the _correct_ program from these
| conflicting changes?
|
| ---
|
| Also for example, an unsophisticated and unsound method for
| automatically resolving some merge conflicts:
|
| 1. Assume that if the build and tests succeed, the program
| is correct. (This is the most important bit)
|
| 2. Accept all non-conflicting changes.
|
| 3. For conflicting changes, accept one side of the
| conflict.
|
| 4. Build and test the result. If it succeeds, merge it.
|
| 5. Otherwise, attempt the same with the other side of the
| conflict. If it succeeds, merge it.
|
| 6. Otherwise, it cannot be merged automatically by this
| method.
|
| Note that this approach could also apply to a CRDT-based
| merge.
| ItsMonkk wrote:
| I'm on a medium sized team so this might not be possible
| for everyone. The way I resolve this in my Trunk-Based
| source control system(so we heavily use Feature Flags) is
| to just never merge.
|
| Every person who is to check-in code is to first stash
| their changes, pull all code, then pop the stash and deal
| with any conflicts locally, do the relevant testing, then
| check-in. The entire repo is checkin 1 -> checkin 2 ->
| checkin 3 -> etc..
|
| When viewed in this light it is no different than if you
| had pulled the baz() code before you started editing
| anything. Would you have changed it to bar() or not?
| ankitdce wrote:
| The product being discussed here doesn't solve the issue of
| merge conflicts itself, but rather of eventual consistency.
| Merge conflicts is only a part of it, and there are some
| heuristics that can be used to reduce those, but eventually
| require manual review. Perhaps with Github Copilot this can
| improve?
|
| An example of the problem we are describing is explained
| here: https://blog.mergequeue.com/managing-github-merges-
| for-high-...
| tobr wrote:
| In real time collaboration, like Google docs, merge conflicts
| can be avoided because you see them play out live, and can
| react to them.
|
| In an offline collaboration system merge conflicts are a
| feature, they bring attention to inconsistencies you might
| otherwise overlook.
|
| This has very little to do with how the data is stored.
| UweSchmidt wrote:
| On the contrary, I for one am amazed how often no intervention
| is necessary on automatic merges, given how finnicky compilers
| are in general! If the teams are not ridiculously large and
| people mostly work on their own stuff and coordinate work on
| the "common" part, isn't it mostly good?
|
| There are certainly usability issues with git but I wouldn't
| literally use Google docs with colored squiggly lines for the
| changes from Anne and Bob...
| eatonphil wrote:
| I don't mean literally Google docs but a storage system more
| like that than git. :)
| ankitdce wrote:
| Feels like this should be a post in itself! This is just my
| opinion so open to any push backs / comments.
|
| IMO the main reasons for source control are: - having revisions
| / diffs that can be reviewed by someone else - while working
| independently in a distributed fashion - easy way to rollback
| to an older revision
|
| I'm not too familiar with CRDTs, will add more comments after
| reading more about it, but let's take Google docs as example
| here. What if we were all writing code in Google docs, how
| would that turn out.
|
| Google docs do a decent job of versioning, so the last point
| can still be satisfied. I think with a source code styled
| version of Google docs, one can easily tag versions and do
| rollbacks. The issue happens when collaborating. Just from my
| experience working in spreadsheets where > 10 users are
| actively trying to modify, overwriting each other becomes very
| common. You can argue that it might make it easy to also fix
| this, but what about running the code locally?
|
| One would have to still take a snapshot - hope that it actually
| compiles. From my personal experience, while I'm writing code,
| it rarely compiles in the first attempt. So then we would
| really have to work on snapshots where we know it compiles. At
| that point, you are really creating "commits" and pushing it to
| the remote. I am not sure if we can really completely avoid
| conflicts in such model.
| gscho wrote:
| How does this compare to Shipit?
|
| https://github.com/Shopify/shipit-engine
| spriha wrote:
| similar to how we compare with bors, actually!
| https://news.ycombinator.com/item?id=27858794
|
| tl;dr: Our goal is to be the absolute lowest-maintenance option
| for your team :)
| neil_s wrote:
| So excited to skip rebase/merge hell! Congrats on the launch!
| spriha wrote:
| Thanks for the support!!
| pulkitb wrote:
| This is great. Congrats!
| horse666 wrote:
| How does this compare to Mergify? https://mergify.io/
| jltino wrote:
| this is awesome! congrats on the launch!!
| [deleted]
___________________________________________________________________
(page generated 2021-07-16 23:01 UTC)