After learning the basics of Git, WordPress developers often struggle to find a nice way for deploying their WordPress sites and themes automatically in a way that compliments their new workflow.
In this post, we're going to take a look at:
- Why you should automate your WordPress deployment workflow
- A couple of the most popular solutions out there
- Setting up a simple way to deploy changes to a WordPress theme whenever you
git pushusing DeployHQ
Why automate deployments in the first place?
Save time
With an automated deployment solution, you won't need to manually keep copying files over to your server when they've changed.
Deploy more often
If you're regularly making small tweaks to your theme, you can just git push after a change has been committed, and everything else will be taken care of automatically, meaning you can spend more time focussing on improving the theme and less worrying about how to make the changes live on your server.
Reduce mistakes
A dedicated deployment solution should only upload the files that changed since your last deployment, so you won't run into a problem where you might have forgotten to upload one of your changed files when doing so by hand.
Multiple locations
Deployment solutions allow you to deploy from anywhere, at any time. With automation in place, any developer with access to the repository can deploy.
Easier for teams
You should even be to allow different levels of access to different users, depending on where and when you want them to deploy. You could set up users who can only deploy to certain environments, such as testing and staging, but not production. Some solutions even allow you to stop deployments going out at 5pm on a Friday!
And then what about:
- Quickly resolving a bug, how do you know which files to change or roll back?
- What if you're deploying to more than one server at the same time - how do you make a consistent process that works across all servers?
- The period of downtime if someone visits the site in the middle of uploading some changes?
- What if you simply don't have immediate access to connect to the server?
These are just some of the problems you'll almost certainly run into when using a "manual" method of updating the website. However, there are a number of solutions for automatically deploying your changes, which we'll outline below, each with their own advantages and disadvantages.
Manually uploading changes
We've already touched on this one earlier in the post, possibly the simplest out of the box, connect to the website server either via a local client, or a web hosting control panel, and upload or remove any files that need to be changed.
Pull down changes using Git directly on the server
A common method is to simply install Git on the web server as well, then when you're happy with your changes, login to the and run git pull, or, you could even add the server as an additional remote and run git push to it.
This will ensure only changed files will be deployed and rolling back to an older version in the event of an issue is just a case of running a git revert, then pushing /pulling that rollback to the server.
Command-line tools
A number of dedicated command-line based deployment tools exist, allowing developers to deploy their website from the comfort of the command line.A popular example is Capistrano, which effectively uses your local copy of the website (via Git) and can allow you to set up commands such as database migrations, as well as multiple environments. This results in something as simple as cap deploy production to start a deployment.
Web-based deployment tools
Last but by no means least, there are several deployment tools specifically designed to help with that part of your workflow. Many de-facto features such as rollbacks, automated deployment, management of multiple environments (staging and production, for example) and the ability to run additional commands are just some of the advantages you immediately get from using one.
This holds all the same advantages as a command-line based tool, but with additional features such as user access control and time-based restrictions, you can ensure only the correct users can deploy, and when.
Deploying your WordPress theme with DeployHQ
DepployHQ is a service that allows you to set up all the necessary steps to make deploying your website simpler, faster and more reliable. There is even a free plan to allow you to deploy a single project.
When deploying your WordPress theme through DeployHQ, you’ll firstly need to ensure the theme file has been committed to a repository host, and your server is set up with WordPress installed. To create your project within DeployHQ, you’ll first be prompted to connect your repository, then asked to enter your server connection details.
You will be able to find the necessary server connection details and credentials within your hosting account. You can also find a series of guides for a number of the most popular hosting providers on our website:
If the user you’re connecting as has access to the full WordPress install, you’ll need to enter a deployment path of “/wp-content/themes/theme-name” to ensure the files from the repository are transferred to the theme’s folder within the WordPress install.
During your first deployment, all files within your repository will be transferred. If these files already exist on your server, you can skip the initial deployment and choose to just deploy the changes going forwards:
Skip deploying from scratch on your first deployment
Enabling Automatic Deployments
You can choose to have deployments triggered automatically upon a push to the repository. If the repository was connected by using the OAuth method, an automatic deployment webhook would have already been added.
However, if you’ve added your repository manually, you’ll need to add the webhook manually also. The automatic deployment webhook can be found within your project, under “Automatic Deployments”.
This webhook will need to be copied over to your repository. From this page, you can also select which servers you’d like to enable automatic deployments for. The branch used for automatic deployments, will be the branch specified within the server settings, on an individual server basis.
Using Build Commands
A lot of modern websites involve installing external dependencies or compiling code for purposes such as reducing the size of client-side JavaScript and CSS.
Doing this, then storing the compiled assets alongside the originals in the repository itself can cause a number of problems such as merge conflicts, so with a dedicated tool like DeployHQ's Build Pipeline you can run these commands in real-time during the deployment, and only have the assets that have changed uploaded to your server.
Just head to your project's Build Pipeline area, add any commands you need to run and DeployHQ will do the rest. You can even add build-cache directives to have certain dependencies saved between deployments, skipping the need to download them from their source each time.
Using Config Files
Several files will be needed for a website to function, such as a config file that contains access information for a local database. Due to the sensitive nature of these files, it's bad practice to store them in a distributed system such as a Git repository. However, with DeployHQ you can add these files to your project as "Config files", keeping them protected and only in one place.
Simply head to your Config files area in your project, then you can add the contents directly in the editor and give it a path to upload to on your server. This will then just be uploaded automatically with every deployment.
These are just some of the many advantages that a dedicated deployment solution such as DeployHQ can provide. You can find even more information about our features on our website, and of course, get in touch with us if you have any questions about how DeployHQ can help with making deploying your WordPress themes easier.
