I use Gitlab a lot. I use it for personal projects and have also implemented it at work - I love the platform. Others are available, but for me, having everything in one place (though risky!) saves me having several tabs open.
I've previously covered what CI/CD is, and why it's great; but now I want to show some examples of it, working within Gitlab, so you too can create fancy looking deployment graphs as shown below.
It is worth noting that Gitlab do have their own pages for CI/CD, however some of the information on those pages is a little out of order, and will cause issues when you try and build pipelines. This .gitlab-ci.yml file referenced throughout this post is available on Gitlab.
Broken down simply, the labels at the top are the different stages, the individual nodes are tasks. Each node has a label, which is what the job is called. This was all built with the following YAML in my .gitlab-ci.yml file (available as v1.0):
stages: - Build - Test - Staging - Release image: ubuntu:xenial build: stage: Build script: - echo "This is the build stage" test:codeLint: stage: Test script: - echo "Linting the code" test:UnitTests: stage: Test script: - echo "running unit tests" test:IntegrationTests: stage: Test script: - echo "running integration tests" stagingRelease: stage: Staging script: - echo "Staging release" productionRelease: stage: Release script: - echo "production deployment" tagRelease: stage: Release script: - echo "Tagging the release"
Breaking down the file, the
stages element is pretty self explanatory, these are the the names of the stages which appear on the top of the pipeline. You don't have to name them, and if you don't it won't provide any. You can call them anything you like, and even call them after emojis (though why you'd want to I don't know - but I don't use emojis):
image element is the Docker image you want to use to do the work. This can be set for each individual job, for example if you need to do integration testing on a Windows image and a Mac image for software. I've used a separate job image to do versioning (I'll come to that later).
Then we're into the jobs themselves, e.g.
test:codeLint: stage: Test script: - echo "Linting the code"
The first line there is the name of the job. The
stage identifies where it fits in the pipeline (this is optional, but advised if you have a number of jobs). The
script element are the series of tasks the job needs to run. In this case, echos the line "Linting the code". That's it. Like I said, the job looks fancy; but I set this up to do nothing on purpose.
The intelligence for any CI/CD job comes from what each stage does, or needs to do, which I'll cover over the next few posts. But this gives an outline of the very basics of setting up a pipeline within Gitlab, and letting it run when the branches are committed.