So, you have worked on WordPress and are ready to deploy it. There is only one problem. How do you deploy your development site without losing all the updates and new content added to the production site as you develop?
What you need is a way to compare your database data development based on data of production, to merge the two databases, and to solve the conflicts, one by one. The only problem is that there is no tool for this (until now)?
Mergebot is a "beta" plugin that aims to solve the problem of database merging, and to do so in an easy to implement manner.
In this tutorial, we'll explore Mergebot, consider the pros and cons of using Mergebot, and highlight some great alternatives for database merging.
How does mergebot work?
What can you do with mergebot in reality:
- You can clone a production site to a development environment.
- You can install Mergebot on the development and production websites.
- As you make changes to your development site, and Mergebot saves these changes.
- Periodically you will have a new copy of the production database and you can use it to refresh the development database.
Each time you refresh your staging database you are using Mergebot to reapply changes to your staging site. This way, your development site will have your latest production data and all of your development work.
Once you are ready to deploy the work on the production site, all you will have to do is access " Tools> Mergebot And press the button to apply all your development changes and see them applied to the production site database.
In the end, you will be able to deploy changes from the development database to the production database without causing data loss.
Let's see how to do things in practice.
Mergebot in action
The first thing to do when you start with Mergebot is to clone your production site to a development environment. Then, once you have your development site set up, install the plugin ' Mergebot On both sites.
With the plugin installed and activated, a notice will appear letting you know what you need to do to complete the installation by adding an API key for each site in the "wp-config.php" file.
Once the Mergebot API key has been set on both development and production sites, navigate to " Tools> Mergebot” on the development site to link the two sites.
Mergebot is now configured. However, he does not control the changes. To start keeping track of changes on the development site, you must click the button on the user toolbar.
Now it's time to make some changes. To test things, we will create an article on the development site. Then I create a new page on the production site.
Let's see what Mergebot picked up:
The wording of the message in the Mergebot page of the WordPress Dashboard (Tools> Mergebot) is a bit difficult to decipher. However, by clicking on " View Queries You will access a new tab that will display all the queries registered by Mergebot.
Looking through the ' changeset " than Mergebot recorded you will notice the changes to the development site that were stored on Mergebot. Now we can update our database on the development site with a new copy of the production database and then apply this " changeset ».
So, let's do it.
Refreshing the development database
Mergebot is designed to work with " WP Migrate DB Pro Which allows database cloning between two connected sites. Use " WP Migrate DB Pro »Allows updating the development database very easily. However, the developer has stated that the use of "WP Migrate DB Pro" is not necessary.
For this tutorial, I did not use " WP Migrate DB Pro ". Instead, I used the free version, to export the production database, then imported the database into my development database using phpMyAdmin.
After refreshing the dev database, I logged into the dev site again and was greeted with a message from Mergebot.
In reality, I would have expected this behavior. But I admit that at the time, I was a little intrigued by this message. How to choose an option to save the requests and then check the Mergebot server for more details?
It turns out that the queries that were captured represented a massive batch of WordPress security keys saved in the database. The generation of these queries appears to have taken place when WordPress was manually connected to the refreshed database. Obviously, I chose to ignore these changes.
Video tutorials included in the Mergebot documentation make the merge process more transparent when using WP "Migrate DB Pro". In this scenario, Mergebot recognizes what you are doing when you refresh the development database and ignores the changes applied by the database refresh.
Anyway, it created a changeset that was annoyingly oversized, but still, it worked very well. I refreshed the database again, this time choosing to ignore the new changes, and then went to " Tools> Mergebot To apply the " changeset ". The result was that the development site included all the changes made on both the production and development database.
That's all for these early days with Mergebot. We will see in a future tutorial how to deploy a changeset and limit Mergebot.