Continuous Integration in Gitlab

Introduce what is CI and how can it be implemented in Gitlab

Introduction

To put it briefly, continuous integration a.k.a CI is a development practice that integrate different codes from different programmers with continuous and automatic building and testing.

The advantage of CI is that you can detect bugs easily and locate them quickly without spending too much time on setting the environment. Everything was once done by finishing or changing the config file.

Here is the SOP for CI — “Plan, Code, Build, Test”. We’ll go further in each section later. Actually, the next step of CI is CD which is the right part of the below picture. However, we’re only focus on the CI in this blog and another post for CD.

SOP for CI/CD

Start planning and coding!

Our team aims to write a code to test the hello function to say to hello to the customer. After that, they finish the hello function as follows.

Code for testing

After finishing the function, they wrote a unit test to check whether the code is working or not.

testing code

Here is the structure of the project floder:

project_folder
|
|-src
|   |
|   |-hello.py
|
|-test
|   |
|   |-test.py

Building and testing automatically

In order to schedule the tasks and set up the environment, we should add the .gitlab-ci.yml at the root of the repo. We first glance around the config file and discuss the detail afterwards.

CI config file

• images

images is to specify the docker image. Here, I choose to use Python image. It is not necessary to specify it.

• stages

stages is used to define the pipeline of the integration. Here, we have build stage and test stage.

• Remain parts are the detail for each stage and should follow the below structure.

<name>
  stage: <stage define in stages>
  script:
    - <script to execute first>
    - <script to execute second>
    - ...
  <option>:
    - ...
  ...

It is self-evident that there are lots of option to use. You can find different option in GitLab doc.

Before building and testing, we should first make the repo and push it to the GitLab.

$ git add .
$ git commit -m "<Your commit message>"
$ git remote add <Your url>
$ git push -u origin master

Result

After the repo was pushed to GitLab, GitLab would determine using which runner to execute the jobs. After finishing building and testing, you can see the result in jobs. If there are no error, you will get both seccess.

Runner

CI runner is the job worker that do the building and testing for your project. Therefore, if you have multiple CI runner, you can do the testing and building more rapidly. To say more about it, the runner will clone your project and do what you ask him to do.

To get or config your runner, you can access the GitLab doc to pick what you need!

Summary

So far, we have introduced what is CI is and why it is critical for the project. In the next article, we’re going to see what is CD and how can we implement it!