In the previous video we installed GitLab CE (Community Edition) using the Omnibus installer. In doing so, GitLab CI (Continuous Integration) was also installed for us.

However, GitLab CI is disabled by default.

Thankfully, enabling GitLab CI is a fairly straightforward exercise. At its simplest, it's a case of editing a config file (/etc/gitlab/gitlab.rb) and running the sudo gitlab-ctl reconfigure command a couple of times.

Why Would I Want GitLab CI?

PHP has moved on significantly in the last few years. Frameworks have become commonplace. We manage our dependencies using Composer. Git has become almost the de facto standard in keeping our code versioned.

But testing lags behind.

I'm not going to rant about testing here in any greater depth other than to say that my current opinion swings towards those who don't write tests either do not understand the benefits of doing so, or are too lazy to try.

One mitigation point to team members being unwilling to adopt a testing mindset is putting the automated test suite as a step that occurs automatically on the server side whenever a git push takes place.

Developers are now sufficiently indoctrinated into the git push cycle that hooking in at this point is a no-brainer. Also, it happens behind the scenes, so no extra work for anyone.

The idea here is that even if one or more team members cannot embrace a testing culture, they will be able to see whether their code has broken the existing functionality that is tested.

Not having to install, configure, or run the test suite locally may be causing some initial friction to the adoption of testing / a quality driven mindset. Therefore once the tests become centralised and visible, the culture and attitude towards testing may start to change.

Whether you choose GitLab CI, Atlassian Bamboo, Jenkins, or any other system for Continuous Integration doesn't matter to me. I only care that quality is maintained, and I firmly believe GitLab CI helps you do so.

If you do not have time for tests, you must have plenty of time for problems.

Real World GitLab CI

The basic guide to Getting Started is here.

As you'll see in the video however, in the real world, you are going to want SSL incorporated into your setup, if you have any inclination towards security.

You need a 24 months / 2 year certificate for this to work. You can either buy one, or generate a self-signed cert for this.

Not a fan of doing things by hand? Try the GitLab Ansible Role, which will handle all the hard work for you. Unsure about Ansible? Check out this tutorial series, it's totally free.

Now Go Forth and Continuously Integrate!

Futher Reading

It would be rude not to mention Martin Fowler's article on Continuous Integration.

Obligatory StackExchange link.


Share This Episode

If you have found this video helpful, please consider sharing. I really appreciate it.


Episodes in this series

# Title Duration
1 Zero To GitLab in 5 Minutes 05:02
2 Continuously Integrate All The Things 05:10
3 GitLab CI Runner Tutorial 03:04
4 GitLab Reset Password 01:42
5 Updating GitLab and GitLab CI 04:52
6 GitLab Backup 15:55
7 GitLab CI Backup 04:20
8 PHP Continuous Integration with GitLab CI 08:08
9 How To Use VirtualBox as a GitLab CI Test Runner 06:02
10 Running Selenium with Docker During VirtualBox Test Runs 09:02