Blog

News from the versioned universe

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 with a little bit of scripting.

By the way, if you want staging for your WordPress site to be really easy, try VersionPress.com. It is a hosted version which also offers other benefits like speed and backups.

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 (Bitbucket, GitLab, …) 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 – git add remote and git push.
  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 is a very useful and powerful command on its own but requires some more parameters like --require or --siteurl, please see the documentation for all the details.)
  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 git push.
  6. You, in the meantime, also made some changes and try to push them using git push. Can you guess what happens?
  7. Correct, GitHub rejects it (non-fast-forward merge) so you first run wp vp pull, similarly to pure Git projects.
  8. You resolve any possible conflicts, e.g. like in this tutorial, and check locally that the site is OK.
  9. You push again using git push. It succeeds this time.

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 takes care of the database.

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.
  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 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.

Thanks for reading and happy versioning!

Discuss & subscribe on Reddit:

r/VersionPress