Elastic

Elastic ships Elasticsearch and Kibana, the search engine and visualization stack behind a long list of production observability and security workloads. Around that core sits a portfolio of projects that all live on GitHub: Beats, APM Server, Fleet Server, Elastic Agent, Logstash, the Elastic Common Schema, and the integrations and docs repos that wrap them. Each one of those is wired to Mergify.

The pattern that pushed the observability team toward heavier automation is the one every long-lived project hits eventually. Elastic ships on a six-week cadence, with main as the active development branch and a series of 8.x release branches kept alive for active releases. Every fix that lands has to be evaluated against every active release branch. Doing that by hand, across dozens of repos, was the kind of work that slowed releases down without producing anything visible.

The merge policy at Elastic splits along an axis most teams ignore. Human-authored PRs need two approvals before Mergify will merge them. Bot-authored PRs (from Dependabot and the company's other automation tooling) need one Mergify approval. In both cases, Mergify is the one doing the actual merge once the rules pass.

The backport flow is the part that does most of the work:

• Backports by label. A PR gets a backport-{branch} label for every release branch it should ship to, or a backport-skip label to opt out. Once the original PR merges to main, Mergify opens the matching backport PRs against each tagged branch. The owner reviews and merges those.

• Forwardports for docs. Documentation updates often land directly on a release branch. Mergify pushes them back to main with a forwardport-main label so the docs don't drift out of sync.

• Assignee notifications. Backport PRs are automatically assigned to the original author, with a reminder if the PR sits unmerged for more than a week. That fixed a real pattern where forgotten backports quietly piled up at the bottom of the queue.

CI is split too: Jenkins runs about 95% of the validation, with GitHub Actions, Buildkite, and Travis CI running on specific projects. Mergify is the layer that turns those mixed signals into a single merge decision.

Across the past 90 days, Mergify has handled more than 5,400 PRs across the Elastic org. The biggest contributors to that volume are Beats, the APM agents and APM Server, Fleet Server, Elastic Agent, and the integrations and docs repos. Most of those PRs land on main and then fan out to the active release branches automatically.

The workflow Victor describes isn't novel on the surface. PR opens, CI runs, reviewer approves, Mergify merges, backport PRs open. The piece that matters is the part you don't see: a six-week release train that doesn't slip because someone forgot to cherry-pick a fix to 8.16 on a Friday afternoon. For an engineering org running this many projects in parallel, that's the difference between a release cadence that holds and one that drifts.