Blog

Moving from DeployHQ to WP Migrate

 

Getting code to a server from local has always been from a repository, where the repo main branch is the single source of truth for production files. Similarly, the staging or dev branches would go to their respective servers and everything would be neatly arranged via the repo. As I have previously worked in large teams, mainly agencies this is really the only way, and should be the only way to keep everything and everyone organised and working on the same thing.

I’ve taken this approach to my own development, also known as the Gitflow method and have organised my branches per server. Over the years, I’ve experimented with different ways of getting files to a server – FTP, Capistrano and now DeployHQ.

Advantages of DeployHQ

DeployHQ is a subscription service which connects a repo to a server and provides an interface for pushing and selecting commits to a server. Because it uses an interface, it gives you that peace of mind that the last fetched commit will go to the right place, as well as offering a test run option. The test run shows which files will be uploaded and is really useful because, say the push contains 3 ACF field group changes, you know that on the server, you’ll have to go and sync those files up. Or, if some css is changed, you’ll need to check/clear cache. Similarly if this is the first time deploying to a server, the new files will be everything in the repo, not just the last commit.

When actively working on a project I make my code changes and then push them to my repo (either Gitlab or Github) and exclude the dist/node_module etc files via the .gitignore file. This gives me a neat and tidy theme or plugin to push to a server from.

It’s also worth mentioning that DeployHQ is owned by Krystal hosting – a company I really admire, and use for my own, and clients’ hosting account.

Disadvantages of DeployHQ

The main disadvantage for me using DeployHQ is the price. When I started on the solo plan I had 10 projects for $9 a month which is really not that bad (with VAT that’s about $10.80, converting to just under £9). Each project gives you unlimited servers so a project is essentially a repo connection. As my clients and projects grew, I had to upgrade and am now on the Business plan with 20 projects a month.

Pricing table from DeployHQ with underlined plans that I have purchased

The second disadvantage for me is the complexity of setting up a project which can take some time. The process roughly goes in this order:

  1. Create new project in DeployHQ
  2. Connect a repo – fill details manually
  3. Add DeployHQ SSH public key to the repo and authenticate
  4. Create a server in the project
  5. In the server cPanel or WPEngine create ssh or SFTP accounts
  6. Save SSH or SFTP details to 1Password
  7. Enter details into DeployHQ
  8. Set deployment path manually from public_html folder
  9. Do a test code deployment with a very small change
  10. Tweak file path if that wasn’t right
  11. Do a full deployment with the code
  12. Rinse and repeat for every server you want to connect to.

That is a lot of steps and as I’ve done it a few times now, I’ve written guides to help speed things up a bit.

The thing is, all that time really stacks up and it differs massively for each server. Sometimes, having access to cpanel in itself can be difficult to get, e.g if working with 2FA (two factor authentication) on login. Or it could be that SSH/SFTP can only be enabled by the hosting support and just doing step 5 in the list above stops you in your tracks.

I’ve been thinking for a long time – it’s just pushing some code to a server, does it have to be this hard?!?!

I’ve decided “No” it doesn’t have to be this hard. The reason tools like DeployHQ exists is they give you so much more than pushing code – they have numerous features for large teams and build systems. This is a bit overkill for what I need. So, I did look around for some alternatives but found that pricing is about the same. Why change to a similar system for a few bucks less a month.

Is WP Migrate the answer?

I’ve been using WP Migrate since roughly 2015/2016 for personal use and had used it in some agencies as well. Back then you could migrate the database but the extra extensions like media library files were paid addons. Fast forward to today, and WP Migrate (formally WP Migrate DB Pro), gives you theme migrations and has all the extra extension bundled into a single plugin. Since working freelance I’d seen the theme migration option, but never used it because I had DeployHQ set up and felt that was the better option.

Now, I realised that the theme migration is the simplest, most effective way of getting my code changes on the server. I already use it to pull the files from production when setting up a brand new site. Why not use it to push the theme as well? It’s almost a bit like “ooooh that feels weird” after doing it the repo/deploy way for so long. It’s time for a mindset shift.

Advantages of WP Migrate Theme files over DeployHQ

As mentioned, now that WP Migrate has the theme files option, I can simply create a migration profile containing just the selected theme and name it something like Push THEME to PRODUCTION. I use capitals to emphasise the direction and server name so it makes me doubly sure.

Because the .gitignore file is not read by the Theme Deployment option, there is a section to exclude those files so they don’t appear on the live site. Here is what I put in that box:

.DS_Store
.sass-cache
.git
Thumbs.db
assets/js
node_modules
node_scripts
tailwind
.editorconfig
.gitattributes
.gitignore
.jscsrc
.jshintignore
.prettierignore
.stylelintrc
composer.json
composer.lock
package-lock.json
package.json
phpcs.xml.dist
postcss.config.js

These are essentially all the build files that produce the final js and css files so are not needed on the server. This part works really well and it supports relative file names/paths.

More info here: https://deliciousbrains.com/wp-migrate-db-pro/doc/ignored-files/

Disadvantages of WP Migrate Theme files

My biggest concern right now with migrating theme files is that I’d lose the knowledge of what files are on the server, because I wouldn’t have a deployment summary to look at. That is one big selling point of DeployHQ to be able to see what the last push was. If I use WP Migrate, how will I know which files are on the server?

At the moment, I won’t know, so I am working on some ideas about how to do this. Some options are:

  1. Being really mindful and always pushing after committing
  2. Sending a notification via slack using Zapier.
  3. Using special keywords in my commit message.
  4. Creating a spreadsheet of commits (😵)

Before I pull the plug on DeployHQ i’ll update this post about my method (I’m thinking option 2).

I will also caveat this blog post and say this method is only really applicable for working solo. Doing deployments via WP Migrate without some kind of log/slack thing would be utter chaos!

Back to blog