Using GitLab CI to Deploy WordPress Sites

So I work with a team that use Git to manage all the theme code for a large WordPress site. It’s a corporate, and as is the way with big organisations, they wanted their version control in house. Hence I set them up a GitLab box. Want to make an alteration to CSS or whatever?

  1. Code & test on your local dev stack
  2. Commit via git & push up to Gitlab
  3. SSH into the server, git pull the new code down
  4. Run gulp build to update the compiled assets

Job done. Wouldn’t it be great if you didn’t need steps 3 & 4 though? They don’t take long in the short term, but get very tedious after a while. They also introduce an element of risk if you have less technical people needing to deploy code that shouldn’t be let loose on the terminal of your production web server…. Hence: GitLab CI to the rescue!

In this tutorial, we’re going to set up a repo so every time code is pushed to master, it gets deployed to a production server, and every time code’s pushed to a branch called develop, it gets pushed to a staging server.

CI is integrated and ready to go into the latest versions of GitLab (my install was on 8.4.4 at the time), so let’s start by creating a file called .gitlab-ci.yml in the root of your repository. This will tell it what to do. I have something like this:

What’s it doing?

  • The script parts of deploy_staging and deploy_production are the commands that will be run on our respective servers. I.e. the commands that we were typing manually into the shell before.
  • The stage part is redundant here. We only have one stage. If we were running unit tests etc. it would be more useful
  • “only” limits the task to a certain branch. Here we have different tasks for our maser and develop branches. They’ll deploy to different servers.
  • “tags” links the tasks to different runners, that we’ll set up below.  

Anyway, save that (or something similar) and commit it to master. Next, we need something to actually carry out these commands. That would be “runners”. Let’s install the multi runner on our GitLab box, which will logon to our web servers for us and run the commands we set above to deploy our code.

Now we need to tell Gitlab about it. In it’s web interface, navigate to Admin -> Runners and note the registration token it displays down.

Back on the shell, you can now run:

and follow the on screen prompts to create a config for your new runner, supplying:

  • The registration token from before
  • SSH connection info to your server (you’ll need public key auth set up)
  • A tag to reference the runner by in your .gitlab-ci.yml (I have “staging” and “production”)

I’ve set up two, on for staging (that will run when code is pushed to the develop branch) and one for production (that will run for master).

Back on the Gitlab Runners admin screen, you’ll now see your new runners, ready to go.

Let’s test this all out then! Make a commit and push it to your develop branch, then navigate to your project’s Builds tab in the web interface. You’ll hopefully see one running. Click it and watch the shell commands you defined in .gitlab-ci.yml running right before your eyes!


9 thoughts on “Using GitLab CI to Deploy WordPress Sites

  1. Hi kanec.

    I´m trying to apply these steps to Gitlab, but when I test the .gitlab-ci.yml file, I received this error:

    Status: syntax is incorrect
    Error: Unknown parameter: deploy_staging
    Error: Unknown parameter: deploy_production

    Could you give me a tip?

  2. It’s worth noting that for whatever reason the indentation of the above .gitlab-ci.yml example has been lost. Use spaces (not tabs) to add indentation, and check validation using the GitLab lint tool

    – deploy

    stage: deploy
    – mkdir /whatever
    – master
    – production

        1. Think the only gotcha I remember with SSH is setting up public & private keys for it. You need to generate them under the right account on your git lab box and add them on the server you’re trying to connect to

Leave a Reply

Your email address will not be published. Required fields are marked *