Setting Up CI/CD on GitLab

With  DevOps taking up the trend we all agree that Continuous Integration(CI), Continuous Delivery(CD), Cloud, Automation and Configuration Management are the basics and everyone wants to learn these technologies
With proper implementation of CI, developers can review code faster and the push takes place after the changes being validated, with a lesser  number of bugs.

What Is CI?

Continuous Integration (CI) is a development practice where developers integrate code into a shared repository frequently, preferably several times a day. Each integration can then be verified by an automated build and automated tests. Among them are revision control, build automation and automated testing. - Codeship

What Is Gitlab?

Gitlab is a lifecycle tool that gives Git-repository manager providing wiki, issue-tracking and continuous integration. It is a complete DevOps platform which that lets professionals to perform all the tasks in a project—from project planning and source code management to monitoring and security.

What Is The Use of CI/CD?

CI/CD is essential to software development using Agile methodologies which suggest the use of automated testing and beta apps to be tested before getting it released to a larger base of users.
I recently had an experience in implementing CI/CD on GitLab and will like to share my experience and the approach I used to do it.

Step 1: Setting Up a GitLab Account

Firstly get yourself on GitLab, finish the signup process and then create a repository and push the project or create a new one to it.

If you already have one configured then let’s move to Step 2.

Step 2: Configuring CI/CD on Your Project

GitLab CI/CD is configured through a file called .gitlab-ci.yml placed in the root of a repository. There are certain scripts and commands defined in the file that is executed by GitLab runners. Once the file is created, we need to edit it to create our own CI configuration that can meet our needs.

Your CI configuration will look like this and should be inside the file - gitlab-ci.yml.

image: node:latest

    stages:
      - build
      - test

    cache:
      paths:
        - node_modules/

    setting_up:
      stage: build
      script:
        - npm install
      artifacts:
        paths:
          - node_modules/

    testing:
      stage: test
      script: npm run test

Now lets understand what above snippet is all about.

The configuration file starts by declaring a docker image best suitable to run your project on.

image: node:latest

Next we define the various stages(processes), of integration

stages:
  - build
  - test

As the stages are defined, now a cache is defined that specifies the file that should be saved for later so it can be used for various stages.

cache:
  paths:
    - node_modules/

Next, are we defining a job as    setting_up  that describes what is to be done in the stage     build?    Typically we are trying to set up the environment to run our project by installing dependencies.

setting_up:
  stage: build
  script:
    - npm install
  artifacts:
    paths:
      - node_modules/

Lastly job testing describes the commands to be run during the stage test. As we cached the folder node_modules, it will be accessed by the job testing to run the command.

testing:
  stage: test
  script: npm run test

The names of the jobs i.e setting_up and testing can be any and were chosen by me, you can have yours.

Step 3: Configuring a GitLab Runner

Since our repository includes a    .gitlab-ci.yml    file that means every commit will trigger a new CI run. And to run the jobs we need a runner  that can be a preconfigured runner by GitLab, triggers on every code push to execute the jobs. But it has some restrictions on it so if you want to configure your own runner, I will recommend you to follow the instructions here.

Step 4: Register a GitLab Runner

As your runner is configured but you still need to register it that binds it with a GitLab Instance. Follow the instructions here. Running the runner executor on the shell is the easiest to setup, so after registration, install and start the service with these commands:

$ gitlab-runner install
$ gitlab-runner start

To make sure the runner is running run this command.

$ gitlab-runner status

If you see this:    gitlab-runner:   Service is running! , then the runner is up and running.

What’s the biggest thing you’re struggling with right now that we as a technology consulting company can help you with? Feel free to reach out to us at info@jalantechnologies.com. We hope our assistance will help!