How To Set Up CI/CD For Your Javascript Projects: An Easy Guide

Introduction

Before you read one more thing I have to say, I have a short story to tell you, One I'm sure will convince you to practice CI/CD.

The Failed Start-up

After bootstrapping (The VC fancy word for grinding) for a few years, a small startup aiming to solve logistics problems by connecting vendors to customers gets funded.

Everyone was happy for this young team. These hardworking teens have won against all odds and can now scale operations. However, three months down the line, they had to fold up.

This story tells you nothing, at least for now, about why you should practice CI/CD, but in the next five minutes, I'm going to highlight why three minutes invested in setting up automated checks can save you hours, and heck, maybe even a startup.

WHAT IS CI/CD

According to GitLab,

Continuous Integration is the practice of integrating code into a shared repository and building/testing each change automatically, as early as possible; usually several times a day.

Did you pick the same thing I deduced from that paragraph? . Well, according to every research ever, only one person can introduce bugs to your code. Guess who, of course the answer is you. Therefore, what is better than setting up automated steps to protect yourself from, I guess yourself? I'd argue pineapples on pizza, but this is not the place nor time.

WHAT ARE YOUR OPTIONS

I'm guessing you are finally connecting the dots between the failed startup story and the need for CI/CD. Of course not. I am deliberately keeping you in the dark. But before I give you the missing piece of the puzzle, what CI/CD options are available to you.

If you are a fan of reports, you might want to read this piece about why engineering teams struggle to deploy faster.

As promised, these are the various CI/CD solutions you have available to you.

We will be exploring how to set up a working CI/CD pipeline using Github Actions.

SETTING UP CI/CD USING GITHUB ACTIONS

Chances are, you already have a project hosted on Github. If this is true, then we have a perfect opportunity. Together, we will integrate a CI/CD pipeline (fancy word really, could have used steps) for the project and confirm that it is working.

Before I go any further, if you have been deploying without tests, then you've got to stop. Honestly, it would take you less than five minutes to write working tests with a test framework like jest. You can also check out this article about why tests are a must.

GITHUB ACTIONS

I love Github Actions for three reasons. There are more than three reasons, but here are the top three:

Trigger test/build by waiting for actions like push or merge or pull request. You know, like event listeners and event emitters.
Skip all the boiler code and get templates. Even better, Github scans your repository and offers a template based on the code present in the repo.
I only have two reasons, but three sounds better than two, you'd agree.

GETTING OUR HANDS DIRTY

Alright, time to roll up our sleeves and do some hardcore programming stuff. Head over to Github and select the repo of your choice and let's fail-proof that mohf**ka.

1. HEAD OVER TO THE ACTIONS TAB

Head over to the Actions tab of your repo, and you will have a suggested workflow waiting for you.

2. SELECT THE APPROPRIATE GITHUB WORKFLOW

Based on the language, Javascript hello, select the suitable workflow. The first suggested workflow is usually appropriate and will serve your need for your first CI/CD.

3. CHECK THROUGH THE WORKFLOW AND CUSTOMIZE IT TO YOUR NEEDS

Let's go through some of the commands in the workflow.

Name: This refers to the name of this workflow and indicates the entry point to every workflow file. Necessary but not compulsory.
On: Like event listeners and event emitters in Javascript, you specify which Github event triggers this workflow. Your options include:
- push
- pull request
- create
- deployment
- delete

You can either select one or provide an array of events that trigger the workflow.

Branches: This option allows you to select which branch the event has to happen before the workflow is triggered.
Jobs: this refers to different tasks assigned to this workflow. Ideally, a single workflow should do one job. Therefore, if you have more than a job, consider creating separate workflows.
Env: Just like the development .env file, it sets up variables for the workflow.
Runs-on: this is an OS configuration set to the developer's operating system. Options include; windows-latest, macOS latest, and Ubuntu latest.
Steps: this is the major component of CI. It involves listing the steps executed by the workflow. Here you will have the name of the step and what it does.

For example, a step named "install dependencies" will run "yarn add" or "npm install." For a step that runs tests. It will run "yarn test" or whatever command of your choice specified in package.json.

After the minimal setup, our workflow should look like this.

workflow.yml

# This workflow will do a clean install of node dependencies, cache/restore them, build the source code and run tests across different versions of node
# For more information see: https://help.github.com/actions/language-and-framework-guides/using-nodejs-with-github-actions

name: Node.js CI

on:
  push:
    branches: [ master ]
# this indicates that this workflow is triggered whenever there is a push on master
  pull_request:
    branches: [ master ]
# or if there is a pull_request on master

jobs:
  build:

    runs-on: ubuntu-latest
#options include windows-latest or macOs-latest

    strategy:
      matrix:
        node-version: [12.x, 14.x, 16.x]
        # See supported Node.js release schedule at https://nodejs.org/en/about/releases/

    steps:
    - uses: actions/checkout@v2
    - name: Use Node.js ${{ matrix.node-version }}
      uses: actions/setup-node@v2
      with:
        node-version: ${{ matrix.node-version }}
        cache: 'npm'
    - run: npm run build --if-present
    - run: npm test

Go ahead and start commit. Voila!, you have successfully added CI to your repository.

Now you can confidently push changes with the guarantee that if anything breaks, you will quickly find out why.

Also, now you can quickly continuously deliver/deploy (hello the CD part) to production if Github workflow runs successfully without errors.

So what happened to the startup? Well, they failed to monitor the quality of goods sent to the customers by the vendors. Soon, their service reviews were filled with several disgruntled customer reviews complaining about delivered products being substandard.

Would CI/CD of some kind have saved that startup? I can't confirm that but I can confidently assert that CI/CD will save your time and your javascript application.

WHAT NEXT

Is there any of your committed apps on Github without workflow?, it takes only five minutes to set everything up end to end. Also, ensure that you write tests that provide a certain level of coverage for your apps.

I will be writing on how you can include a higher level of specificity and functionality to your workflow and how you can also cache your dependencies to improve your workflow speed. Sounds interesting, then connect with me on Twitter and Github or send me an Email. Till next time, Have fun coding.