Methods of deploying a site

(Ulrich) #1

I having being trying to find a way to best deploy a WordPress site.

These are my constraints:

  • shared hosting
  • includes git
  • site code hosted on GitHub
  • WordPress is added as a submodule
  • use the git repo on the server so to be able to use git status to check which files have changed when hacked

I tried a few methods with the pro and cons:

  1. Set up a bare repo on the server and add the server as a remote location that can be pushed to from the local repo.
  • Pros: Can easily push from local repo
  • Cons : Unable to update the submodule with a hack
  1. Create a non-bare repo on the server and connect using SSH and run git pull
  • Pros: Works without a hack
  • Cons: Requires logging in via SSH to update
  1. Use a service like
  • Pros: automatically update the repo using shell commands.
  • Cons: It costs extra per repo
  1. I have looked for some code that would use the GitHub hooks but not found anything yet that would work on a shared host.

How do you deploy your sites?

(Joel Warren) #2

Mostly (sigh) for simple sites I purely use git for my tracking changes and not deployment and upload via FTP.

For sites where I’ll be deploying a few times with updates/fixes etc, I use

Saying that I’d like to find a better way.

(Jon Bukiewicz) #3

Joel, that’s exactly the same process that I use.

(Jason) #4

For me it depends on what I have available to me for the project. Here are my preferences in order:

  1. Host the site on WP Engine and use their automated git system (simple push/pull) and staging system
  2. Use Capistrano. The requisites are: git is installed and I have SSH access (non-sudoer is fine). The biggest issue here is actually the fact that the site would be stored in (for example) /public_html/wordpress/current – and some shared hosts (which I avoid anyway) don’t make this easy.
  3. Simple git push/pull as mentioned above. I make changes, log in, and pull.
  4. I haven’t had to do this in a long time, but if the host is stupid and refuse to support git or SSH, then I’ll use ftp. But I’d really rather not.

I can almost always do either method #1 or #2, though. For database migration, I use WP Migrate DB Pro (a game changer).

(Jimmy Smutek) #5

I also deploy via FTP and use git only for version control.

I work locally with a MAMP setup and push changes to staging on my VPS via FTP for files, and WP Migrate DB Pro for the database. Once the project is ready for launch I move it from my VPS to the clients hosting service the same way.

I’d also like to find a better way. My method is fine for a completely new website, but I start to hit bumps when I’m working with a client who has an existing site and who blogs regularly. As the project moves along the live site gets more and more out of sync with my development copy.

I looked into git deployment, and have git installed on my VPS, but I couldn’t quite get my head wrapped around it and had to move on for lack of time.

(Ulrich) #6

@jasontheadams How do you set up the site repo? What is your structure? I have heard that WP Engine update core and plugins for you. How does that work with git?

The biggest issue here is actually the fact that the site would be stored in (for example) /public_html/wordpress/current
How is this an issue?

Thank you everyone else for your replies.

(Kalen Johnson) #7

I personally have been using Laravel Forge, it’s not specific to Laravel. Basically, it can spin up a Digital Ocean server for you, provision it, set up projects (like WP projects in a Git repository), and set up automatic push to deploy. It will do a Git pull for you, and it can run extra scripts, so if you use Grunt or gulp.js to build css/js for you, it can handle all that.

I have one $10 / month Digital Ocean server I’m using for staging right now, and it’s great to put projects up I’m working on, and take down when they’re not needed anymore.

It sort of combines having a VPS you would need to provision yourself, and a more expensive managed VPS. I don’t think it will continue to make updates for you, although there are “recipes” for updates that you can run. Overall it’s been the missing link for me, and for $10 / month to completely handle what Capistrano and other pay-for services do, I love it.

(Jason) #8

It’s a straight-forward wordpress repository with all the core files, plugins, and my theme. The trick is the gitignore file ignores all the core files. And WP Engine doesn’t update the plugins for you, just the core. I have my local git origin set to bitbucket, and a remote production and staging set for WPE. So if I want to push something to the repository and deploy to staging, I’ll do something like: git push origin staging && git push staging staging. So bitbucket is always my main repository, and I just push to WPE when I want to deploy.

It’s only an issue because some hosts make it a pain to redirect the vhost for the domain to be a sub-directory of public_html. So points directly to public_html/. Some, like Dreamhost, have this as a setting you can easily change; others you have to put in a request for them to do it… when they get around to it. :wink:

(Jason) #9

That looks pretty cool! What’s primarily kept me from using Digital Ocean for clients is that I just don’t feel I can offer that good of a backup service. Not like I could with WP Engine or one of those guys, and they’re so amazingly tweaked for proper caching and CDN, it’d take me a lot of work to even come close.

To be fair, I wouldn’t lump capistrano in that group. It’s not a pay-for service at all, it’s a deployment framework built in ruby. It doesn’t cost me anything to use it, just a bit of time to tweak the config files from one site to the next.

(Kalen Johnson) #10

For sure, and I didn’t mean to lump them in. My reference was basically “I’m paying for the provisioning / GUI for this, and I get what Capistrano basically does along with it, and don’t need to pay for other services.” But you’re completely correct, Capistrano is open source and free to use unlike other pay services that do something similar.

(Russell Heimlich) #11

Here is a Git Ignore template I use for easy version control of a WordPress site It makes it simple to choose which plugins or themes you want to version control using Git and will ignore everything else.

As for deployment you can use a webook from Github that will call a PHP file that will run Git commands to update the repo on your server. See as an example.

I run Git on my own server and use hooks to trigger deployments to staging sites. This is what that looks like Once it’s set-up it’s drop dead easy to push a commit and have it updated on the server a few moments later. You could even kick off other processes that should happen on deployment like sending an email out to someone or compiling some code.

(Ulrich) #12

Jeremy Felt shared a few deployment workflows and so did Tim Nash.

There is was even a further discussion here on WPChat: Development Workflows


Have you tried out Cloudways? It is similar to Laravel Forge. However, there are some differences. With Cloudways, you can directly launch a managed server from the platform. No need to launch a server separately and then connecting it with the platform, like in Forge. This means you only have to pay to the platform provider, unlike Forge.