Julien Thierry
Software Engineer
Prophesee 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. Engineering consists of a few dozen developers working on different software layers.
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
Hardware + Multi-Layer Software = Highly Complex Workflow
While the company produces and integrates hardware, there is also a team dedicated to software for controlling the sensors and 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 to establish communication between it and the system in which it is integrated (USB connection, etc.). We find a team dedicated to the algorithmic and application part at the opposite end of the spectrum. Between the two, we find Julien and Olivier's team, which provides the link between sensor communication and access to stable functionalities.
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.
Julien Thierry
Software Engineer
A Heavy Mental Workload
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 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.
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.
Julien Thierry
Software Engineer
Modernization and Automation For an Efficient Workflow
As part of this spring cleaning, 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.
Integrating Mergify automated many manual tasks relating to merging processes, 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, the development branch creates a new branch. All changes are made to this new branch. Once satisfied, the developer 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 cannot avoid all the quality-related rules that the merge queue automatically executes.
