Remote Workflows

Currently, the commands for cloning and merging only work locally, meaning that you cannot, out of the box, create a staging environment on a different server. That is often desirable so I’m going to show how you can achieve that today with a little bit of scripting.

By the way, if you want staging for your WP site to be really easy and don’t want to mess with CLI scripts, we’re close to releasing a beta of something interesting in this space. Email me at borekb@gmail.com to join the Insider program.

Understanding the (non-)magic

Even though seeing two databases merge seamlessly feels like magic, the process is quite straightforward:

  1. Git repositories are pushed / pulled between the two site clones, e.g., production and staging.
  2. wp vp apply-changes is called to update the database on the target environment.

That’s it. Whenever you’re going to script remote workflows, keep these two core steps in mind.

Now let’s move on to some real-world examples.

Example 1: Team work via GitHub

You are a developer and have a colleague, Jane, who helps with design and copywriting. You both want to work on the site in parallel and manage the team work via a private GitHub repo. This is how it would work:

Please note: the CLI commands below are not complete, e.g., are missing some parameters. It’s just to give you an idea.

  1. You start on your machine: create a WP site, install VersionPress in it and do the work as normal – install plugins, create some initial content, write some PHP code, etc.
  2. You set up a GitHub repo and push to it using wp vp push (or even git push but let’s stick with the safer wp vp commands).
  3. Jane clones the repo to her machine using git clone.
  4. Jane runs wp vp restore-site to get a fully working WordPress site. (This already is very useful; I remember how happy I was when it worked for the first time.)
  5. She makes some changes, e.g., changes the site title, chooses a different theme and updates it a bit. Her Git repo contains new commits and she pushes them to GitHub using wp vp push.
  6. You, in the meantime, also made some changes and try to push them using wp vp push. Can you guess what happens?
  7. Correct, GitHub rejects it because the changes are non-fast-forward.
  8. So you run wp vp pull (for pulling, don’t ever use the plain Git command; the WP-CLI command handles database merging). You resolve any possible conflicts, see this tutorial, and check locally that the site is OK.
  9. You push again using wp vp push and see it succeed.

Steps 5 to 9 then repeat in some order. It’s basically as if the project was plain Git, the main difference is that you use wp vp pull instead of git pull which makes sure the database is synchronized.

Example 2: Pushing to production

You have a local copy of a WordPress site and then a production server running the live site. You want to push your changes to the live site directly (for an alternative using a middle man, see Example 3 below). Do this:

  1. Set up networking between your machine and the production site. Git supports several protocols, the most common being HTTPS. For example, all GitHub repos are accessible as something like https://github.com/versionpress/versionpress.git, you can set up a URL like this for your production machine as well.
  2. Push to this remote URL (git push or wp vp push, it doesn’t quite matter).
  3. On the remote server, set up a post-receive Git hook to run wp vp apply-changes.

This is basically it, Git again will enforce that you can only push fast-forward changes, otherwise, you’ll need to pull first.

☝️ Note that the remote site should be in a maintenance mode while the synchronization is running, even if for a couple of seconds. We don’t have a good support for it yet which is why this workflow is unofficial.

Example 3: Pushing to production via GitHub

In this scenario, you push your changes to a GitHub repository (or Bitbucket, GitLab, whatever) and then have these changes deployed to a live site. It’s probably the ideal setup.

Again, you would use hooks. Depending on your setup, a CI server can, for example, be notified of the changes via GitHub webhooks, pull all the changes from the GitHub repo and push them to a live site, similarly to Example 2 above. The details will depend on your concrete setup.

Summary

As you could see, remote workflows are very powerful and VersionPress is the first tool to enable them in a pretty straightforward manner. Whatever workflow is possible with pure Git, is possible with a VersionPress-enhanced WordPress site.

Leave a Reply

Your email address will not be published. Required fields are marked *

Some HTML tags are supported