WordPress deployment flow

To err is human — this age-old saying might come from a time when the first lines of code were yet to be written, but it still rings true today. Making mistakes is unavoidable, especially when repetition is involved. In deploying websites, repetition permeates the entire process.

If your site is complex enough, you may need to run a certain number of NodeJS (installing scripts, SCSS to CSS conversion, etc.) or Composer (installing libraries, running tests, etc.) tasks to begin with. You’ll then need to transfer all files to the server, clear the cache, and make sure everything works the way it should.

Even though they’re repetitive, these tasks are not that hard to handle — when you're flying solo, that is. The more people start working on one project, the more complicated it gets.

Luckily, you can make it simple and error-proof through WordPress deployment automation.

In this guide, we'll explore how to automate repetitive tasks and make your deployment process a breeze with Buddy. Let's get this show on the road!

Single Source of Truth: The Git Repo

Before you start transferring files to a server, let's think about what you can do to ensure that every team member working on your project has access to the same files — this includes all changes introduced by others. You can get all of that with Git. Without getting into much detail about Git itself, here are a few things this version control system gives you:

  • Access to the up-to-date version of files for all collaborators.
  • Detailed change history.
  • Branches: a way to work on changes in isolated environments.

When you start using Git, you can say goodbye to overwriting changes prepared by other devs and forget the days of figuring out when and where the buggy code was written.

Git screenshot

There are many ways to use Git:

  • Using the command line.
  • Through tools built into popular code editors, such as Visual Studio Code.
  • With dedicated tools such as Gitkraken or Git Tower.

Let's also think about the things you should keep in a Git repository. There are many strategies and approaches to this and they change depending on what you're working on. To start our journey, I recommend using a .gitignore file with these contents:

# Ignore everything in the root except the "wp-content" directory.

/*

!.gitignore

!wp-content/

# Ignore everything in the "wp-content" directory, except the "mu-plugins", "plugins", and "themes" directories.

wp-content/*

!wp-content/mu-plugins/

!wp-content/plugins/

!wp-content/themes/

With this configuration in place, the repository will store only the files from wp-content/plugins, wp-content/mu-plugins, and wp-content/themes.

I recommend reading this GitKraken article to get started with Git.

Connecting the Repository to Buddy

After you set up the repository, connect it to Buddy. First, choose where you host your files. Choose between GitHub, Bitbucket, GitLab, Buddy Git Hosting, and a private Git server.

Choose where to host your files

When you connect the repo, Buddy encourages you to add your first action and start automating.

Adding your first action in Buddy

Adding Pipelines

What is a pipeline? Think of it as a set of actions carried out in the specified order, triggered by an event of your choice.

Adding a new pipeline in Buddy

When you add a new pipeline, you must define its name, choose the trigger (manual, push to the repo, recurrency), and choose the branch which the pipeline handles.

Click “Add a new pipeline” to reveal a list of actions.

Select an action from the list

Building Assets and Installing Libraries

Thanks to package managers, such as Composer or npm, you can make your life much easier when it comes to managing package versions and ensuring that all installed libraries or packages are compatible with each other.

Additionally, you can get a lot of things done using scripts run with Composer or npm:

  • Converting SCSS to CSS
  • Running unit tests
  • Checking code for errors with linters or PHPCS

However, before you start adding actions to your pipeline, I recommend reading these articles:

Now that you know how to use these package managers, let's handle the actions. To add Composer to your pipeline, add the PHP action and enter these lines in the action's terminal:

cd wp-content/themes/THEME_NAME

composer install

Add the PHP action

Next, install libraries and run npm scripts. You can handle this by adding a NodeJS action and entering these commands in the action's terminal:

cd wp-content/themes/THEME_NAME

npm install

npm run build

The npm run build command isn't universal — your app might use a different command to trigger builds. Check the package.json file to find out what command is used for building.

Find out what command is used for building

At this point, your pipeline should look like this:

A screenshot of a pipeline in Buddy

Unit Tests and Code Analysis

So the website is ready for deployment — all libraries downloaded, all assets built. Now it's all about uploading it to the server, right? Before you do that, how about you run some tests that check if the code you've written works the way it should?

You can handle this testing stage in a couple of different ways:

Depending on your specific needs, decide which tools and approaches are right for you.

Use Composer to install the tools you need and add new commands to composer.json, for example:

{

"scripts": {

"test": "vendor/bin/phpunit",

"phpstan": "vendor/bin/phpstan analyse src tests"

}

}

After you handle the tools, add a PHP action to your pipeline and add these commands in the action's terminal:

composer install

composer test

composer phpstan

Add commands in the action's terminal

Now your pipeline should look like this:

Updated pipeline in Buddy

Deploying to a Staging Environment

At this point, not only do you have your code all ready, but it's also checked and tested for any bugs. Time to deploy to production? Hold your horses, cowboy!

First, let's deploy the site to a staging environment. If you have a Nexcess server, creating a staging environment is extremely easy. Just follow this guide and you'll be done in no time.

With the environment ready, it's time to transfer all the files there. Use the SFTP action in Buddy to handle that. Remember to specify the right remote path — the directory to which the files are uploaded.

Transferring files in Buddy

It's a good idea to use the action's Ignore paths tab to specify the list of files and directories you don't want to upload to the server, e.g. node_modules.

Once everything's uploaded to the staging server, you have to make sure that no additional actions run without your specific approval. Why? The fact that the code has been thoroughly tested doesn't automatically mean that you want to push it to production right away.

Sometimes the QA team wants to click around and check a few things manually. You should give them a chance to do that.

To facilitate that, add the Wait for approval action which stops the execution of any downstream steps until the person with the right permissions approves it.

Add the wait for approval section

With that said, here's what your pipeline should look like now:

Updated pipeline in Buddy

Additional Tests

I know it's tempting to just approve the execution, get it over with, and deploy the app to production. But bare with me — let's run some more tests and make sure nothing's broken. It's worth it, believe me!

Buddy has a couple of actions you can use to run additional tests. You'll be happy to hear that they require almost no additional configuration.

Let's start with Visual Tests, which are regression tests that allow you to check if the look of the specified sections hasn't changed in an undesired way. To get this going, simply add a list of pages we want to compare. If Buddy detects differences between the pages, you'll have to give it a green light to mark the action as successful.

Adding visual tests in Buddy

Next, it's worth checking if our changes don't have a negative impact on the Google Page Speed rating. We don’t want to slow down the page load time. To measure that, you can use the Lighthouse action. All you do is specify the page you want to test and the thresholds for results.

Using the Lighthouse action


The last thing that's worth checking is if all links on your site actually work. To do that, you can use the Link Validator action, which checks if any of the links on your site return the erroneous 4xx or 5xx status responses.

Use the Link Validator action

Is this all you can do? Of course not! I won't describe EVERYTHING, though. We've covered the most universal and useful cases, but feel free to read up on some more interesting actions here.

Here's what your pipeline should look like after adding all of the additional tests:

Updated pipeline in Buddy

Deployment to Production

Okay, now it's time to deploy to production. Finally!

The first step — enable maintenance mode using WP-CLI. To make this happen, add an SSH action, configure server access details, and add these commands in the action's terminal:

cd public_html

wp maintenance-mode activate

Thanks to this, the user will get an appropriate downtime message when you upload files to the server.

Next, add the SFTP action, which will transfer all files to the server. The action's config will be very similar to the one we used to transfer files to the staging server:

Transfer all files to the server

Then add another SSH action which disables the maintenance mode. Add these commands to the action's terminal:

cd public_html

wp maintenance-mode deactivate

With all of these steps done, it's a good idea to notify all of the relevant people using Slack, Telegram, or other communication media. Read more about all available integrations here.

Don't stop at sending notifications when everything goes according to plan. It's a good idea to communicate when something goes wrong so that your team can jump in and fix the errors ASAP.

Here's what the final pipeline looks like when you're using Slack for notifications:

Updated pipeline in Buddy

Now You Know WordPress Deployment Automation

Thanks to WordPress deployment automation and tests, deploying to production won't give you nightmares anymore.

While implementing the presented flow might take you a while, nobody says you can't add these steps gradually.

You can start easy with just building your assets and deploying. Then it's worth spending some time adding tests to the mix — start with the ones that don't require too much configuration, such as PHPCS or PHPStan. Alternatively, you can go with the testing actions that Buddy offers — Visual Tests, Lighthouse, etc.

When you're ready, bring out the big guns and add the tests that you have to prepare by yourself, such as PHP Unit or Cypress.io.

In need of hosting that’s optimized for WordPress? Check out Nexcess’ fully managed WordPress hosting plans today.

Maciek Palmowski
Maciek Palmowski

Maciek is a WordPress Ambassador at Buddy passionate about all things related to web development. He is a speaker & organizer of CMS-related events in Poland. After hours, apart from cycling – which he loves - he spends most of his time looking for a cutting–edge (well, ‘interesting’ is enough) news from the CMS world to share with the community of his followers.

We use cookies to understand how you interact with our site, to personalize and streamline your experience, and to tailor advertising. By continuing to use our site, you accept our use of cookies and accept our Privacy Policy.