Firas Khalife
Built by me · internal tooling

Release merge dry-run

Before every staging and production release, several teams’ branches must merge cleanly. I built a dry run that does it first, in the background, and tells the right person what broke.

BeforeManual merge prep; problems found at deploy time.
AfterRuns in the background; problems caught first, owner already told.
How a dry run goes
1 / 5Every team’s branch, in a throwaway worktreeThe branches due for release are checked out in disposable worktrees, so nothing anyone is working on is touched.
  1. 1Every team’s branch, in a throwaway worktree
  2. 2Git, but only in approved shapes
  3. 3The release merge, ahead of time
  4. 4Migrations checked against staging
  5. 5Clean → PRs. Conflict → a note, not a guess

What it changed

01Staging deploys saved, more than once
02Fewer deploy issues from DB scripts and startup errors
03Checks against the staging DB that never existed before
04Run in rotation by other teams
How it stays safe
Isolation
Throwaway worktrees: nobody’s work is touched
Git
A guard hook allows only the exact commands the procedure uses
Migrations
Failure prediction, read as MySQL 8 reads them
Data
Read-only staging database, through the MySQL MCP server
The full story

Before every staging and production release, several teams’ branches must merge cleanly. The dry run I built does it ahead of time in throwaway worktrees, opens the release PRs for DevOps to merge, and stops on a conflict instead of guessing a fix; the owning developer gets a clear, drafted message. A guard hook lets git and GitHub through only in the exact shapes the procedure uses.

How migration failures are predicted

It applies the migration tool’s own rules for naming, versioning and checksums, reads each statement as MySQL 8 will, and replays the release against the staging schema and data through a read-only MySQL MCP server.

khalifefiras29@gmail.comgithub.com/FirasKhalifelinkedin.com/in/firas-khalife