Mergebot is finally out of the bag. Brad Touesnard has been talking about it for quite some time on his Apply Filters podcast, but they’ve now posted on the Delicious Brains blog more about the why and how of MergeBot.

Here’s the big pitch:

Mergebot combines the benefits of scripting and the (fictional) magic merge tool without any of the negatives.

You install the Mergebot plugin on your local and live sites. Then as you make changes locally your changes are sent to our cloud app (mergebot.com).

Later, you can safely refresh your local database by replacing it with the live database then running Mergebot to apply your changes. Not only have you refreshed your local database, you’ve also just tested a database deployment locally. You can continue developing and refresh your local database regularly, testing your deployment regularly.

If some data changed in the live database that you’ve also changed locally, Mergebot will detect it when applying changes and present a nice UI asking you to resolve the conflict. It will also save this resolution for the next time you refresh your local database or when it comes time to deploy to the live site. That is, you won’t ever have to resolve the same conflict twice.

When it’s time to deploy to the live site, put the site in maintenance mode, deploy your code changes, then execute Mergebot to deploy your database changes. Since you already executed Mergebot locally (probably a few times), resolved the conflicts, and tested, you’ll have confidence that it will all work.

Deploying changes and merging local and live websites does indeed suck. If Mergebot does what it promises, it will undoubtedly find success, and they’ll also have their massive WP Migrate DB Pro userbase to market to.

There are other tools with similar promises, at various stages of their life cycles. Two come to mind from a content deployment perspective. RAMP, by Crowd Favorite, was at one time a go-to option for content deployment — but not so much site management deployment — and I probably wouldn’t recommend it today. WPSiteSync is also an attempt to manage content deployment, but it’s a young product with a long way to go. Still, content deployment (while also an issue) is less of a problem than full site merging.

VersionPress is attempting to solve database merging, like Mergebot, but in a very different way, as WP Tavern highlights; VersionPress has also had a complex life of its own, from a failed crowdfunding campaign to a $400,000 round of fundraising.

I would love to see both VersionPress and Mergebot succeed. I can’t stand the process of deploying new features to a website. Take, for instance, my much-discussed-and-trolled-about job board. Launching such a feature is a pretty big task, with a lot of configuration necessary at the database level, in addition to files. Mergebot could help with that, and I would welcome it. I personally think a hosted SaaS is a smart way to handle this kind of product, which Mergebot is going to be.

You can read, and should read, Brad’s entire post about the motivation behind Mergebot and the year it has taken them to get to this point. They are currently seeking early adopters, if you’re willing to live on the bleeding edge.