It should come as no surprise to anyone involved in software development that keeping all code in a version control system is best practice and has been for over 20 years. My version control repository of choice has been BitBucket for a long while. This was initially due to their first class mercurial support that they offered plus the ability to create private repositories (all for free). But it quickly dawned on me that every self respecting developer should have a GitHub profile and public repo’s for the world to see. It was originally the social networking aspect of GitHub that made me join, but it was its great UX and ease of use that made it my primary Git repo.

I had first heard of Gitlab when Digital Ocean began offering 1-click images to install on their servers – giving users total control of their Git Repo without the monthly cost. But it wasn’t until their dreaded database incident where I began to pay close attention. Shortly after I had joined up to trial it out. Understandably it was a bizarre time to sign up given the nature of the incident but I appreciated the transparency and the manner in which they handled the situation (plus they offered private repositories for free!)

To discuss the merits of a CI platform would require a write-up of it’s own. Suffice it to say I needed one and had spent some time researching on some free hosted solutions (with Travis CI being on the top of my list). It hadn’t dawned on me that my hosted Git service, Gitlab, had a CI solution all along.

How it works

Gitlab CI uses a hidden file in the Git repository you’re building to instruct the CI engine how to build, test, and deploy the resulting build artifacts. This hidden file – the .gitlab.yml is all that is required to triggers the CI pipeline. The following is a sample I’ve used for a Gradle Spring Boot project:

image: java:8-jdk

variables:
    GRADLE_OPTS: "-Dorg.gradle.daemon=false"

stages:
  - build
  - test

before_script:
    - chmod +x gradlew
    
build:
  stage: build
  script:
    - ./gradlew -g /cache/.gradle clean assemble
  allow_failure: false

test:
  stage: test
  script:
    - ./gradlew -g /cache/.gradle check

In the sample above I’ve defined a Java Docker image on which the jobs will be executed on. For this given pipeline I’ve also defined 2 stages.

1. Build – Runs the gradle Assemble task that compiles followed by building the artifact
2. Test – Runs the gradle check task which runs all the verification tasks in the project, including test.

All that’s required now is committing and pushing the code up. Gitlab’s picks it up, CI triggers a job and the gradle commands specified in the yaml file are executed.

The CI dashboard is clear and concise. It details all running jobs, past and present along with a status once completed.

Clicking through one of the jobs then displays the jobs trace.

Summary

• GitLab CI has reduced the barrier of entry for developers wanting to get into the world of Dev Ops. It’s feels lightweight and convenient. I also personally like the fact that my Git Repo is sitting side by side with the CI.
• A great price point (FREE) provided you stick to the generous limit imposed on free accounts.
• No real gotchas so far but I have yet to trial it out with any complex projects.

Disclaimer, I have zero affiliation with Gitlab. Their solution simply rocks. Admittedly, Gitlab CI is not as powerful as Jenkins but it’s such a no brainer to me that Gitlab combined their CI with their core Git server. I don’t plan on moving to another Git/CI/CD hosted solution anytime soon.