How To Get Started With GitLab CI/CD? - Part 1

Dear Friend

Let's face it. Cooking delicious food isn't easy, So building a CI/CD Pipeline. Both need consistent practice to become good at it.

Today we can take a small step towards it.

Why GitLab?

Three reasons why you need to consider using GitLab.

1. GitLab has features such as cloud-native support
2. Built-in static code analysis.
3. It supports every phase of an SDLC and its SaaS, i.e. a lot less effort at your end.

Jenkins is a most sophisticated tool too. But it requires a bit of heavy lifting from your end.

Gitlab's CI/CD and Jenkins can be compared with manual and automatic transmission.

Some prefer the thrill of the manual transmission. And Some go for the effortless cruising.

For now, let's get started with GitLab.

Step 1 - Create GitLab Account by signing up, skip this step if you have an account

Step 2 - Create GitLab Project

You can create project by navigating to Menu --> Projects --> Your projects --> New project

But to experience the GitLab CI, you can just fork the spring-boot project i created for you.

Step 3 - Trigger Pipeline execution

After Forking the above project, you are all set to invoke the CI. To do that

• Open .gitlab-ci.yml in the root of your project
• Change the echo text from echo "Building Maven Project..." to echo "Building a Maven Project...On Friday!"

The change is not limited to .gitlab-ci.yml. You can change any file inside the project to trigger CI.

After changing .gitlab-ci.yml you can see what's happening in pipeline by navigating to

CI/CD --> Pipelines

You can see the build status marked as passed, as mentioned in the below screenshot.

Congratulations! Now, you have experienced a simple pipeline execution. Let's see things that are behind the scene and help this to happen.

GitLab Architecture

The architecture has two main components

1. GitLab Server - Source control. And Commands GitLab Runner to complete the jobs upon a commit to the repository.
2. GitLab Runner - Receives command from GitLab server and executes the job. A runner is responsible to execute the jobs as per the specification in .gitlab-ci.yml.

.gitlab-ci.yml

This file holds the pipeline configuration and the name needs to be same as mentioned here. Let's explore different parts of the configuration file and their role in continuous integration.

On the above screenshot, line number 1 handles pulling the latest maven docker image. This is like installing a maven on your local to execute a maven project.

In line number 3, the stages field defines the sequence of execution. In this example, we have only one stage called build. But there are other stages such as Test, Package and Deploy. Unless we mention this sequence, all jobs will try to run at the same time.

In line number 6, The job that will be executed on the runner. In this example, the job will compile the maven project.

P.S: To simplify getting started with GitLab, many steps were skipped. Unit tests, static code analysis, and deploying to a server, to name a few. And we will be covering the steps in the coming weeks.

#devops #gitlab #cicd #continuousintegration #devopsstories