Blogs

On this particular section, i will be writing only on problem solving topics and how i conquered them.

06 FEBRUARY, 2019

How to set-up a CI/CD environment on Gitlab using NodeJs.
Read More

How to set-up a CI/CD environment on Gitlab using NodeJs.

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!

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:-

    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

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.

    image: node:latest

Next, we define the different continuous integration process it will run.

  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.

   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.

    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.

    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.

Step 4: Register the Gitlab Runner

Next, register the Gitlab Runner by following instructions here. 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

Conclusion

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