CI/CD and basic setup on GitHub Actions

I’m not sure how it’s like before we automate the process of deployment but I know that I would not want to go back to that time. Imagine having changes (regardless of size) on the code base, we’ll need to build it on our machine, publish it for the others to download, and repeat this for every changes, not to mention if we work in a team, we need to wait for the others if we work on features that depends on each other. If you want to have more insight on how life was before CD/CI, people have a small discussion here.

1. What is CI/CD

CI is the abbreviated form of Continuous Integration. CI helps frequent merges to the main branch and automate unit testing.

CD is the abbreviated form of Continuous Delivery/Deployment. CD helps shorten release schedules.

This is an automated procedure that helps speed up the development process to bring the final product to end users.

CI/CD has been widely adopted by IT enterprises as it’s a great combination with DevOps and Agile. A simple CI/CD is as below:

• Developers commit their code.
• CI/CD will automatically run, build, test and deploy projects to stages.
• User can see the project after deployment

2. GitHub Actions

There are many integration tools, but you’ll probably see GitHub Actions alot. What it allows us to do is to create these workflows when someone pushes something to a git repository. I can make certain steps to take place in order to make sure that everyone’s code is in the same format, all tests are passed before final review and merging.

There are some basic words you might want to know before starting the implementation:

• Workflow: a configurable automated process that will run one or more jobs. Written in YAML file and are defined in the .github/workflows root directory of your project.
• Event: a specific activity in a repository that triggers a workflow run. (ex: pull request, push,…)
• Job: a set of steps in a workflow that execute on the same runner. Each step is either a shell script that will be executed, or an action that will be run.
• Runner: a server that runs your workflows when they’re triggered. Each runner can run a single job at a time. GitHub provides Ubuntu Linux, Microsoft Windows, and macOS runners to run your workflows; each workflow run executes in a fresh, newly-provisioned virtual machine.

3. Basic implementation of CI/CD

So, basically, to trigger Github Actions, all you need is a workflow file. This file will tell Github what action to run and when to run it.

There are 2 ways to create a workflow file. Either you create it from scratch, or, modify it from a template.

From template:

• Go to repository of your working project
• Select Actions tab
• Search for the library you’re using or what you want action to be trigger towards
• Select Configure
• Start configuring that template and save. This workflow file will be saved in your repo.

From scratch:

If you find that the template is quite complicated and you want to create a simple workflow on your own just to see how it works. Create a any-name-is-fine.yml and refer to below:

// in the yaml file, give the workflow a name
name: Test Continuous Integration
// and on what event this workflow being triggered
on:
  pull_request:
    branches: [ master ]
// each workflow should have 1 or more job
jobs:
  // name of the job
  test_pull_request:
    // which machine to run on. Available options are Ubuntu Linux, Windows, or macOS operating systems.
    runs-on: ubuntu-latest
    // then set a set of steps (instructions) that help build and test our code
    steps:
        // you can add name for each step to be more specific, but it's not compulsory. Always start with a checkout, which will bring your source code into current working directory in the runner
      - uses: actions/checkout@v2
        // setup node if you need to
      - uses: actions/setup-node@v1
        with:
          node-version: 12
        // then run the command as you do on your local machine
      - run: yarn config set ignore-engines true
      - run: yarn install --frozen-lockfile
      - run: yarn lint
      - run: yarn build

This means that on every pull request to master branch, Github Actions need to run yarn config -> yarn install -> yarn lint then yarn build

This is how it looks like if someone forgot to run lint check before commit, and there’s any errors.

And this is how it looks like if all checks are passed.

If you add a rule to protect the master branch you can also block merging if checks are failed. This will prevent any accidental merges.

There are many other existing sets of actions that you can use or refer to. And you can search for those actions here.