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?
- Code & test on your local dev stack
- Commit via git & push up to Gitlab
- SSH into the server, `git pull` the new code down
- 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:
stages: - deploy deploy_staging: stage: deploy script: - cd /var/www/htdocs/wp-content/themes/your-theme - git pull - npm install - bower install - gulp build only: - develop tags: - staging deploy_production: stage: deploy script: - cd /var/www/htdocs/wp-content/themes/your-theme - git pull - npm install - bower install - gulp build only: - master tags: - production
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.
curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-ci-multi-runner/script.deb.sh | bash apt-get install gitlab-ci-multi-runner
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!