One of Back Market's
DevOps Engineers
Back Market is the leading global marketplace where tech is reborn, bringing high-quality professionally renewed electronic devices and appliances to customers in 17 countries. Back Market aims to ignite a global change for a more sustainable way of consuming technology – doing more with tech we already have.
Back Market’s in-house release system was resource-intensive to maintain and improve, requiring significant time and personnel.
The custom solution was unreliable and difficult for developers to debug and comprehend, leading to increased frustration and support requests.
The bespoke system could not accommodate the diverse and specific use cases of Back Market, restricting its effectiveness and adaptability.
The in-house solution comes with several issues
Before using Mergify, Back Market experienced several issues, most of which were organic to the company's vast and fast expansion.
Focusing on Back Market's workflow, the company did not have a dedicated team to take ownership of the issue and find areas for improvement.
Back Market works on a big monolith using a highly custom release process. This process relies on scripts to merge or pick Pull Requests depending on several conditions, labels, owners, etc.
When they decided to move out of the monolith, they built a custom release system driving the release pipelines. Unfortunately, this in-house-built system did not meet their expectations. Indeed, developing his own system consumes a lot of resources. And they needed more time and people to maintain it or make necessary improvements. Consequently, the system was quite buggy and painful for developers due to random failures.
That being said, the idea was already here. The Developer Experience team implemented a feature similar to a merge queue. Indeed, developers could not merge pull requests themselves, and they were automatically added to a queue and tested with the last merged pull request.
Then, the Developer Experience team faced something quite common when you developed your own solution: its scope. The team found itself confronted with a great diversity of use cases, ever more specific and numerous. However, not all of these scenarios had been anticipated, and the solution could only respond to a small part of them.
Finally, their system showed natural limitations in terms of feedback and UX. Whether a pull request was merged or taken out of the queue, detailed feedback to the developers wasn't easy to give. So, the Developer Experience team had to deal with a considerable volume of support requests because the errors were—as we have already seen—tough to debug.
To summarize, they gave up on their custom system because it was hard for the developers to debug it, for the dedicated team to maintain it, and to iterate. Fair enough!
Main pain points:
Supporting the solution: maintenance, improvements.
Reliability: It was hard for the developers to understand.
Customization: The scope of their solution was relatively narrow, and no specific issues were addressed.
Productboard doubled its engineering team in just one year, from 70 to 150 people. This was a huge problem for their front-end repository, which consists of a single repository for everything.
To face this challenge, they deployed a merge queue, but they scaled faster than the queue could handle the load. Things weren’t working very well, so they had to use nonoptimal tools to merge the first pull request in the queue, update the second one, run all the checks again, and merge the result.
The time needed for the checks in between was around 25 minutes for each pull request. In 24 hours, they had a hard limit on the number of commits they could merge.
Moreover, most engineers are based in the Czech Republic; during peak hours, engineers could spend a couple of hours before getting their pull request merged. That was the situation they were trying to solve: a bottleneck.
The situation escalated quickly. People were waiting 4 to 5 hours to merge their changes, while their goal was to merge around 150 pull requests a day.
That was the breaking point and when they decided to switch to Mergify.
I'm really impressed by the reactivity of the engineering for the feature. Most of all it happened when we already had signed the contract, so it was not to make us sign. The only aim was customer satisfaction, and that is very, very valuable.
One of Back Market's
DevOps Engineers
Why does Back Market bet on Mergify?
Looking actively for merge queue Literature and GitHub automation, Back Market found out about Mergify through the notoriety of its CEO, Julien Danjou. Julien contributed a lot to open-source projects, and his name popped up when Back Market was looking for a solution. Some people mentioned him and Mergify, and that's how they started to consider the solution. Moreover, since they built one in their previous release system, the Back Market team was already familiar with the concept of a merge queue. With these elements, it was pretty natural to give Mergify a try.
During the evaluation, Back Market's team saw that what they needed still needed to be implemented into Mergify, including some specific features. For sure, they wanted a merge queue but not a basic one. Back Market discovered a new feature on the verge of being implemented: the fast-forward merge. A game changer. During the POC phase, the fast-forward merge was not implemented. It was done three days later. Did someone say responsiveness?
Besides the features, another thing that helped Back Market to decide was UX. They loved how Mergify provides the checks and a summary of all the rules. The developers appreciated that. Mergify's UI saved the Developer Experience team a lot of headaches and support. Indeed, they are not front-end developers and tend not to write their own UI. Regarding dynamic staging environments, they just had to write about respecting a label but not managing it and, consequently, a scheduler.
Finally, Back Market also realized Mergify was highly customizable using the various rules it provides. At first sight, they understood they could use Mergify to simplify automation, among many other things. This customization left a lot of room for creativity and determination.
They came to a statement: abandon their release system, scale back and build a new one, less ambitious and specific to one or two tasks, or use Mergify.
With Mergify, you can give power to the developers because it's in their own repo. They can extend and start using it more and more because we don't really pay based on executions; we pay based on seats.
One of Back Market's
DevOps Engineers
Optimized and efficient workflow, happy developers
Still moving from the monolith, Back Market's workflow appears more optimized than ever.
Evolving in a dynamic staging environment, Back Market implemented Mergify's Merge Queue - a must-have - and uses its speculative checks features to merge using a fast-forward method.
Luckily the Back Market team found a way to prevent manual merging within Mergify and today, there is no manual intervention for merging pull requests. Everything is automated. The developers code, create pull requests and label them. At this point, Mergify takes control. Each pull request is automatically rebased, tested, and merged — depending on CI output.
With the update method rebase they implemented via Mergify, Back Market also prevents squash merges or merge commits and can keep their history linear.
In addition to optimizing their workflow, Mergify has brought many benefits to Back Market's developers. According to Mathieu, Back Market’s developers love Mergify way better than their custom solution. When it came to the Developer Experience team, they saw their workload shrink. The Developer Experience Team saves around 5 to 10 hours of support workload each week compared to their in-house solution. It also saves their developers much more when releasing the monolith with a huge number of PRs in the works.
In addition, using Mergify gave power to the developers, making them happier and more autonomous. They can use Mergify as they want and pimp their workflow with automation rules.
Finally, while if it is challenging and complex to estimate, Mathieu observes that Mergify helps Back Market save money. Indeed, Mergify avoids rebuilding their artifact after merges, costing 10 to 20mins of CI time on the monolith.
