How Mergify optimized Prophesee's development process while lightening the developers' mental load.
Simplify and improve collaboration and visibility between developers
Achieve a very high level of automation across the entire workflow
Improve both Developer Experience and Team Velocity
Prophesee is a French startup and winner of the French Tech 120 award. It is a pioneer in the development of neuromorphic sensors. While these sensors may sound like conventional RGB cameras, they're not. Prophesee's sensors are sensitive to changes in light intensity and are "event-based". This means that they do not return color images, but only events, data relating to changes in luminosity. In addition to a hardware team, the company also relies on a team of several dozen developers working on different software layers. Among them, we met Olivier, Engineering Manager, and Julien, Software Engineer.
Hardware + multi-layer software = a highly complex workflow
While the company produces and integrates hardware, there is also a team dedicated to software, both for controlling the sensors and for exploiting the data flows they generate. Olivier Georget and Julien Thierry are part of this software department, working on the "Metavision" project. The aim of the latter is to provide a C++ and Python API for developers/end-users to develop algorithms and applications using Prophesee sensors. An open source version is available on Github under the name OpenEB.
Within this project, several teams work together and coordinate their efforts. One team is dedicated to the so-called low-level software, which is as close as possible to the sensor in order to establish communication between it and the system in which it is integrated (USB connection, etc.). At the opposite end of the spectrum, we find a team dedicated to the algorithmic and application part. Between the two, we find Julien and Olivier's team, which provides the link between sensor communication and access to stable functionalities.
Julien Thierry - Software Engineer
If I had to remember just one Mergify command, it would be backport. It's so useful, it's surprising not to find it natively in GitHub. It's a real time-saver when you want to fix something on the main branch and port that fix to different releases. In addition to not having to do it by hand, it ensures that we don't forget a single commit.
A heavy mental workload and (too many) manual actions
While the organization and structuring of Prophesee is, by nature, quite complex, it's interesting to understand what led the company to adopt a solution like Mergify.
In fact, it's a logical progression. In fact, the software team already had a merge queue, but it was a totally manual process. Here's the concept: on a dedicated Slack channel, a developer wishing to merge a pull request had to modify the chan topic and explicitly state the following: "I wish to merge such and such a pull request, corresponding to such and such a ticket, in such and such a branch". If another developer wished to merge his pull request, while indicating that he had rebased himself on the first pull request in the topic, he could add his pull request to the topic. And so on. So everyone knew where the team stood in its planning and merge process. Once the first PR had been merged, the first developer would delete part of the topic, leaving room for the next.
In addition to the lengthy topics, this system inflicted an incredible mental load on the engineers. What's more, it was far from being a real security gag for the code base, since it depended on the goodwill of the engineers. Indeed, it was not uncommon for an engineer to come and merge changes without indicating this on Slack.
Finally, as neither the build nor the merge was automated, this system demanded a high level of responsiveness and monitoring from the engineers. In fact, they had to launch the build and monitor it before triggering the merge.
All that was missing was a trigger: a change of stack and a migration of the Atlassian suite to GitHub.
Modernization and automation = an efficient workflow
It was as part of this spring cleaning that Olivier and Julien's team turned their attention to optimizing and modernizing their overall stack. Having access to the GitHub ecosystem, Olivier asked to integrate, among others, Mergify, a solution he had tried and adopted in another organization.
By integrating Mergify, many manual tasks relating to merge processes were automated, drastically reducing friction with GitHub.
Following the renewal of its stack and the integration of Mergify, Prophesse relies on a highly efficient workflow. When a ticket is created on Jira, a new branch is created from the development branch. All changes are made on this new branch. Once the developer is satisfied, he creates a pull request via GitHub to integrate his changes into the "Develop" branch. This is where Mergify comes in. Each pull request must be tested via their CI orchestrated by Jenkins and pass the various checks. When this is the case, Prophesee engineers trigger entry into the merge queue via an explicit label: "ready to merge". Once the PR has been merged into the "Develop" branch, the CI is triggered again via another merge queue, with the aim of merging it into the main branch. This is a safety and redundancy door, as the "Develop" branch is always rebased and up to date. So if the build works on "Develop", there should be no problem on the main branch.
If changes are made to a release branch, Olivier and his team use Mergify's backport command.
Finally, as far as the "release" part is concerned, the whole process is still largely unautomated. As the solution isn't SaaS, Prophesee doesn't use continuous deployment and works by release, updating the software versions installed at their customers' sites.
In addition to productivity gains, the merge queue facilitates the onboarding of newcomers, since it enforces the application of the software team's rules and best practices. A new team member will not be able to avoid all the quality-related rules that the merge queue automatically executes.
Julien Thierry - Software Engineer
I'm a big believer in rebasing before merging, so having a tool that encourages this good practice is great. Plus, if you don't like doing it, you don't have to do it by hand, so it's a win-win situation.