When I was giving what little advice I have about WordPress Hosting, I gently said:
ISN’T IT FRIGGIN CRAZY THAT NONE OF THEM WANT TO HELP YOU WITH DEPLOYMENT?
I wasn’t entirely correct there, some hosts are helping. Even my beloved Local will happily push a local site to production. I just don’t love that because it’s not Git-based.
I’ve long been at the point where I’m not going to work on a web project without there being an automated deployment process. This can take various forms, but typically it’s Git-based. Merge to main, site deploys. This became a defining characteristic of the Jamstack movement and is now clearly such good DX that it’s obnoxious not to have it.
I know Jamstack is a fading term, but it’s still evocative of a certain type of hosting. “Static with benefits,” as it were, typified by Netlify, but common to Vercel, Cloudflare Pages, Render, and the like. These all “run your builds”, which is a nice feature in that it keeps your built files out of the repo, which people generally agree is a good thing. Heck, even GitHub Pages will run your Jekyll build, and was one of the first sites to work in that way. I also like to credit Heroku for being the first host that I know of that was like “we should build the tooling that helps our customers deploy to us”.
But WordPress isn’t Jamstack.
I would think most WordPress deployments don’t run a build at all, they just move new files into place, so a fairly easy task all things considered. SFTP with a brain for diffs.
It feels like a cruel oddity that the type of website that is easier to deploy is more difficult to do so.
I’m able and willing to put in some footwork to have Git-based deployment. It’s nice to get it “for free”, but it’s so nice that it’s worth some work.
Years ago, I would use Beanstalk for this. Beanstalk itself would be the Git repo home, you’d push to that, and it would deploy anywhere you configured it to by giving it SFTP credentials. Beanstalk is still here and still doing that and it’s a fine tool, it’s just… not GitHub. It feels a little weird to use a non-major Git provider and not benefit from the feature set that comes with that.
Speaking of non-major Git providers, WP Engine offers to handle Git-based deployment this way. They host the repo. Weird. I’d rather not give up on all the nice stuff on GitHub like PRs, inviting people in with specific access, issue trackers, etc.
I want to click a few buttons and point at a repo on a major Git provider and say “there, deploy from that.” That’s how SpinupWP handles it and that looks nice to me. Same with Cloudways, if slightly less elegant.
These days, I use Buddy for the same task I used to use Beanstalk for. I find Buddy a pretty nice tool, and the pricing is within the same ballpark. Buddy considers itself more of a full-on CI/CD tool in the vein of CircleCI or Travis CI. Except Buddy is way friendlier because it’s not like YAML configuration; it’s a UI. Hey good name I guess. I like how I can easily tack on other tasks like “Clear the Cloudflare Cache”, “Find/Replace to help cache-busting”, and “Send a Slack notification.” by clicking some buttons. I’ve never used DeployHQ but it looks like it has similar vibes.
If you don’t mind (or like) configuring your CI/CD process with YAML, and you like the idea of using GitHub, you’re in luck! That’s what GitHub Actions literally is. You can configure it to do… pretty much anything a computer can do. It also should be mentioned that GitLab had CI/CD way before GitHub and does well at it.
For WordPress deployment via GitHub Actions, you pretty much it to do one job: move files over SFTP. This looks like the main plugin to help with that, although there are options, like this one from the same maker if you require SSH. My own host Flywheel recommends that approach. Want Git-based deployment? Do it yourself with GitHub Actions and one of these generic actions. Even WordPress.com suggests this approach if you have one of their plans that offers SFTP access. Eh — I’d like better. Debugging GitHub Actions is nobody’s favorite thing to do, and you just know it’s not going to go perfectly.
Some web hosts take the GitHub Actions route by, offering their own GitHub Action… action. Not a WordPress host, but that’s how Begin rolls. I know I picked on WP Engine above for having that weird “we host Git for you” thing, but they do have a GitHub Action also, which surely is much easier to use. I’d probably like to have at least that if I was going to go down this road.
I use a GitHub Action that I tried to strip down as much as humanly possible. It uses git-ftp directly, and nothing else: https://github.com/kaelri/engard.me/blob/master/.github/workflows/publish.yml
As you say, this feels like a backwards and decidedly fragile method for the seemingly-obvious need to “put my files someplace where actual software can use them.” I’ve looked at Buddy and similar services, but I went with the GH script because it seemed almost equally distasteful to add yet another moving part to our web stack. At any rate, I’m very open to better ideas!
Some useful stuff here, Chris – thanks. We use DeployHQ which is great but I’m gunna check out Buddy as it looks like it could be cheaper.
Another tool I’ve always loved is https://gitftp-deploy.com/ but sadly Jan stopped developing it – real shame as it was very solid, and a really useful sort of self-hosted DeployHQ…
Here’s what I do:
Each theme I write is a repo.
Each plugin I write is a repo.
They can be public or private repos.
I then have a plugin I’ve written to inject my repos into the normal wp-admin updates queue if their version number in GitHub is higher than their version number on the web server.
It wasn’t easy, I spent a lot of time writing that plugin.
There is also the excellent Girhub Updater plugin by Andy Fragen.
DeployHQ fan here. My WordPress site’s repo is on GitHub. I set up a DeployHQ project that watches for pushes to a production branch. When it sees one, it auto-deploys to my web host.
It’s worked great. I don’t have a complex site with DIY plugins and such but I’m confident DeployHQ could handle it as it has a ton of options for building and various hooks into the deployment process (that a non-devops person like myself can understand).
I like WPEngine’s “Git Push” feature and have used it often. You don’t need to give up GitHub for that. In fact you shouldn’t. You just use GitHub as normal and then add the WPE repo as an additional remote repo on your local machine. Whenever you push to the WPE repo, it just deploys whatever you pushed (no matter the branch name, last I checked). You never really clone or pull from the WPE remote. You just push to it.
I feel like this is mostly just down to the fact that there’s a wide spectrum of ways that people handle WP in git, as well as a variety of ways people use different build processes within their WP sites. This all makes it tricky to standardise a CI/CD product around a process which is usually different from team to team.
Like where is your git root, is it in wp-content? or root of WP?
Where is WP core coming from? installed via composer perhaps? or included by the hosting provider?
Where do you run your build command from and where is it defined? Root package.json? Perhaps you need to include a composer install build step and also run some build commands within a custom plugin you’ve included in the project?
I can see why lots of hosts will just tell you to write your own CI/CD file and use Github actions.