How to set-up a CI/CD environment on Gitlab using NodeJs
Tags: gitlab, node, ci, intro
Published: 2019-02-06 01:16:18

---
title: How to set-up a CI/CD environment on Gitlab using NodeJs
published: true
description: This is a beginner introduction on how to use and understand Gitlab CI/CD environment.
tags: #gitlab #node #ci #intro
---
So I decided to start my first article on dev.to by discussing how to set-up Continuous Integration (CI) and Continuous Delivery (CD), feedback is welcome it helps!

![](https://media.giphy.com/media/3o7TKsJEd0lp7GNUpq/giphy.gif)

Continuous Integration (CI) is a practice that requires developers to integrate code into a shared repository several times. Each check-in is then verified by an automated build, allowing teams to detect problems to fix early.

Continuous Delivery (CD) is a software engineering approach in which continuous integration, automated testing, and automated deployment capabilities allow software to be developed and deployed with minimal human intervention.

Having a proper CI/CD environment will enable bugs to be caught earlier and developers can review code faster and fix it.

By the end of this article, you will have the basic understanding on how to set up a CI/CD environment on Gitlab.

### Step 1: Create a Project on Gitlab

Gitlab is a web-based Git-repository manager, where code can be hosted. Sign up for an account if you do not have one, or log into your existing account if you already have an account. Create a repository, you can name it anything you like, you can also choose to either make the repository public or private. A public repository is accessible to the public through search or direct access using the project’s URL, conversely, a private repository is only accessible to members invited to the repository by the Owner or Maintainer. 

### Step 2: Setting up your CI environment 

To setup a CI environment, you will need to create a file named `.gitlab-ci.yml`  and it should be in the root of your repository.

This file contains a steps by step description on how your project will be built. The Gitlab runner will search for this file in your repository and execute it. GitLab CI looks for this particular file within your repository to determine how it should test the code.

You can create this file through your already created Gitlab project or via your terminal. I will be using terminal in this tutorial. I love my bash commands😏😏

Open your terminal and move to the directory where the project file is located then create a file named  `.gitlab-ci.yml` by doing this:-

`$ touch .gitlab-ci.yml`

Next we have to edit the `.gitlab-ci.yml` file so we can create our CI configuration by doing this:-

`$ nano .gitlab-ci.yml`

The CI configuration will look like this and should be inside your `.gitlab-ci.yml` file:- 

```yaml
    image: node:latest
    
    stages:
      - build
      - test
    
    cache:
      paths:
        - node_modules/
    
    install_dependencies:
      stage: build
      script:
        - npm install
      artifacts:
        paths:
          - node_modules/
    
    testing_testing:
      stage: test
      script: npm test
```

Let’s understand what the above snippet is all about

![](https://media.giphy.com/media/aBN66chr4Y9na/giphy.gif)

The configuration file starts by declaring a docker image that allows you to specify a certain version of NodeJS you want to use during build time. 

```yaml
    image: node:latest
```
Next, we define the different continuous integration process it will run.

  ```yaml  
    stages:
      - build
      - test
```
Now we’ve defined the stages, the configuration includes a `cache`  that specifies files that should be saved for later to be used between runs or stages.

 ```yaml   
    cache:
      paths:
        - node_modules/
```

Next is `install_dependencies`,  in the process of  demonstrating the interaction between stages, we are extracting this step to run its own stage. Typically, running  `npm install` can be combined with the next testing stages.

```yaml 
    install_dependencies:
      stage: build
      script:
        - npm install
      artifacts:
        paths:
          - node_modules/
```

Lastly,  `testing_testing` declares the command that will run the test suit, Since this is the last stage, it will access what is been produced by the `build` stage, which are the project dependencies in our case.

```yaml
    testing_testing:
      stage: test
      script: npm test
```

Oh yea, `testing_testing` is just a name I used, you can name it anything you want.

### Step 3: Installing Gitlab Runner

Since our repository includes a `.gitlab-ci.yml` file, any new commits will trigger a new CI run. If no runners are available, the CI run will be set to "pending".

As mentioned, in GitLab, Runners run the jobs that you define in `.gitlab-ci.yml`. I will be following the instructions [here](https://docs.gitlab.com/runner/install/osx.html).

### Step 4: Register the Gitlab Runner
Next, register the Gitlab Runner by following instructions [here](https://docs.gitlab.com/runner/register/index.html). 
Running the runner executor on shell is the easiest to setup, so after registration, install and start the service with this commands:

`$ gitlab-runner install
 $ gitlab-runner start`

To be sure your runner is running run this command:

`$ gitlab-runner status`

If you see this:  `gitlab-runner: Service is running!` and the green tick on the project you created on gitlab

![Alt gitlab screenshot](https://thepracticaldev.s3.amazonaws.com/i/0defp5cgmdjb69b6yrz9.png)

### Conclusion

Hopefully this article has widen the borders of Gitlab CI/CD and enriched your understanding and like I said earlier feedback is welcome and just in case I missed something kindly notify me.