Developers face a unique challenge in the era of stringent data privacy laws like GDPR and SOC2 compliance. This article delves into how developers can access necessary data without compromising user privacy, specifically focusing on PostgreSQL databases.
Recently, our team experienced a breakthrough in database performance debugging, all thanks to Datadog's automatic explain queries feature. This powerful tool has saved us countless hours and significantly streamlined our debugging process.
With growth comes a responsibility to ensure our operations' safety. This responsibility prompted us to delve deeper and rethink traditional security approaches, especially concerning cloud integration.
APIs are everywhere. They became ubiquitous over the last years and every startup building a product is now ordered to offer them. They became a major selling point for any SaaS business. Engineering and product teams focus on the design of their API, from top to bottom, making sure they
As you may guess, Mergify relies a lot on third-party APIs like the Stripe API [https://stripe.com/docs/api] or the GitHub API [https://docs.github.com/en/rest] and their behavior. Like any third-party service, we need to deal with many things to ensure our integration never breaks.
It's not a secret that we are fans of Redis. We've been leveraging it since day one at Mergify to store various volatile data. It's fast, robust, and easily scalable. Six months ago, we introduced speculative checks [https://blog.mergify.com/announcing-speculative-merge-queues/] support for
If this title does not ring a bell, you might need to read first what a merge queue is, what problem speculative checks solve, and how mixing speculative checks and batching can save you a lot of time. Go ahead. We'll wait. Now that you have an idea
In every engineering team, developers want to see their "ready to merge" work landing as soon as possible into their source code repository. Nobody wants to wait, and this directly impacts the velocity of the team. The worst part of the merging process would be to have to
Today, we are pleased to announce the general availability of the Mergify API. This has been one of our focuses over the last months, as it has been one of the most requested features from our beloved users. We are thrilled to release it and are eager to add more
When Mergify started to automate pull request merges, users expressed rapidly the need for having a way to keep their pull requests updated. We soon introduced the strict mode [https://docs.mergify.com/actions/merge/#strict-merge] for the merge action, offering pull request merge serialization. This was our first, very
A year ago, we wrote about our workload issues [https://blog.mergify.io/handling-300k-github-events-per-day/] and how we were handling 300k GitHub events per day. Our main challenge was avoiding GitHub rate limit and quota system while delivering service with low latency and high throughput. Earlier this year we noticed more
Last month, we announced [https://blog.mergify.com/announcing-time-based-conditions/] a new set of conditions for Mergify rules based on time. You can now use a time and date and compare pull request attributes to dates and times. We had the idea for this feature since the beginning of Mergify, but