From a merge train to continuous deployments

"If one person wasn't managing merges, we'd run into the ‘dance of merge’. Merge from master, wait for end-to-ends to finish. Oh, another came in, do this again. This slows down everything as a result. You have a very fast team that ends up at a choke point because it's tough to deal with a lot of PRs.

One night, we were in the middle of a large release cycle, Shippabo’s 2.0 release. I had been managing 13, 15 PRs. So I would list out, ‘here’s the order these are going in’, but it’s late, and I’m like, I should look at something else because this is not something I want to be dealing with as the team scales."

‍

"I didn't want something that caused us more headaches or reduced our flexibility in a tradeoff. I found a couple other merge queue products, but when I got down to the documentation, there were certain rules that were effectively enforced. There's nothing wrong with being opinionated, but I didn't want a situation where it's much tougher to introduce something that says we need to change the way we do things that already work.

I needed something seamless that could fit into our existing workflow without actually having to retool anything."

‍

"Aviator was an immediate, and massive time saver. Definitely a sanity saver for us. One of the reasons we weren't doing releases more often than every couple of days was this contention point that was tough to deal with. Since then, we deploy all the time.
‍
The only thing that's being done is waiting for the build to conclude. Aviator for the most part has wiped out everything other than maybe a 10 minute conflict at the very last PR."