Servers, WordPress

Deploying to WP Engine from a GitLab pipeline – CI/CD

WP Engine is a very popular WordPress hosting platform, it has a lot of great features like super simple backups and auto staging site creation and replication. Sadly the methods available for deployment aren’t great. Out of the box you can:

SFTP upload changes

Just like we did we in 2010, you have the option to upload files by hand. This isn’t a great option for multiple reasons:

• It’s time-consuming.
• There is no real way to roll back a set of changes easily
• When working in a team, there is no real indication of what files have, or haven’t been updated recently.

Please do not use this method

Git Push

On the face of it, Git Push sounds like a great option, yet there are a number of caveats.

Any Push is deployed

The deployment mechanism on the WP Engine side is simple, you push something to their Git repository, they’ll deploy it to your environments. Sadly this isn’t isolated to the master branch, so you can be working on a new feature (on a random branch), Push up your code to share with other developers and before you know it, your half competed work is now live 😓.

To get around this, the simplest solution is to use an external Git hosting service like GitLab, Github or Bit Bucket etc. Most development teams would probably already be doing this so it shouldn’t be too much of a burden.

So, whether you use a GUI or Git on the command line, you can set up two separate Git remotes. One will be your development repository, the other will be WP Engine,

This will work fine, there is only one issue… The high possibility for user error. All it will take is one accidental push to the wrong Git remote and you will have triggered a live deployment of possibly half-finished code.

Create a deployment pipeline

In this example, I’ll be using Gitlab, yet the principle applies to any of the major Git hosting services. Before we create a deployment pipeline, let’s consider how we would like it to flow.

1. A developer works on a feature on their local machine.
2. This developer pushes their code to a development Git repository on an isolated branch during development.
3. When the feature is ready, a merge request is created to update the master branch.
4. On merge request completetion / signoff, the pipeline is started to push these changes live.

Why is this better?

One important factor here is that the master branch on the development repository can be locked with a feature called ‘protected branches’:

This means that code can’t be pushed directly to the master branch and has to be added via a merge request. Adding this two-step process means simple accidents are far less likely to happen.

Add the pipeline

To get the pipeline created, add a new file to the root of your project named .gitlab-ci.yml. Then populate with this:

You will need to replace the WEBSITE string inside the script with the location of git repo on WP Engine. You can find these details via the admin here:

Lastly you will need to setup an SSH key pair and deployment variable as per this guide. This will allow a random Gitlab runner to connect with WP Engine securely and only at time of deployment.

So on next commit that gets to master (via a merge request), a pipeline job will be generated.

If everything has gone well, you should receive a Job Succeeded note at the end of the deployment.

You now have an automated deployment pipeline and code review process ready to go!