Prophesee × Mergify
How Mergify optimized Prophesee's development process while lightening the developers' mental load.
❌ Test After Merge
In order to keep the integration of changes and the merging of pull requests, some teams are tempted to launch their tests after the integration. In practice, this is a very bad idea since this strategy will inexorably lead to constant errors and reverts.
❌ Run Global and Automated Tests, All the Time
On the other hand, some teams want to test the quality of the code pushed as a whole to ensure the security of the code base. Thus, the entire test suite is sometimes launched on each pull request. This results in an explosion of CI time and therefore of your budget.
❌ Test, and Test Again
Moreover, running all your tests on your pull request does not ensure that it can be merged eventually. Indeed, if another pull request is merged just after all your checks are done, you will have to update it and run all your tests again, thus doubling the CI costs of your pull request.
😭 Many engineers are dealing with these problems every day.
🦾 Using a merge queue solves that problem by letting you set up a smart testing strategy. This strategy is executed in two steps:
1️⃣ Before entering the queue: run your small tests
Before sending your pull request to the merge queue, you only need to run your lightest unit tests ensuring the validity and quality of the pull request.
2️⃣ Before merging, at the end of the queue: run your big tests
When the pull request reaches the top of the queue, and is therefore ready to be merged, you run all your biggest tests, the most demanding ones like your functional or end-to-end tests.
These tests ensure that the changes can be properly integrated, without risk to your code base. Testing the pull request when it is about to be merged, and just after its automated rebase, ensures that it will always be up-to-date when all the tests are running.
You won't have to test the same pull request several times.
✅ No more manual updates or rebases after testing.
✅ No more broken production.
✅ Less CI time and costs: test only when the pull request is up-to-date and ready to merge.
To go even further, you can use batch.
This feature allows you to update, test and merge several pull requests at once.
By setting your batch size to 6, our Merge Queue creates a new pull request composed of the next 6 pull requests in the queue.
This new pull request is rebased, and the tests are run on all the commits from the 6 pull requests. If there are no errors or conflicts, the 6 pull requests are merged in one go.
If this feature allows you to improve your velocity, it also allows you to reduce your CI costs since you don't launch 6 CI jobs but only one on all the changes.
✅ Automatically rebase, test, and merge many pull requests in one go.
✅ Run fewer CI jobs, save CI time and money.
✅ Improve your Developer Velocity while crunching your CI budget.
Sounds like a dream, right? It's not, just a premium Merge Queue.
Our Merge Queue allows you to establish test strategies to reduce your CI, maintenance, and support costs.
Define a smart, and automated testing strategy with our Merge Queue. Trigger and run the right tests at the right timing.
By using the Batches feature, you can drastically reduce the number of CI jobs needed to test and merge your pull requests.
Understand how to setup the merge queue to split your CI jobs and test your pull requests intelligently and leanly.
Sometimes, a video says more than a thousand words. In this video.
Fabien will present you our Merge Queue solution thanks to a screen recording of the tool.