Here I am trying to marathon writing the last 5 articles before the semester ends lol. I hope I can still English by the end of this.

This time I’m writing about CI/CD. Another word similar to it is automation, which I like to use :D Because why do something manually when you can automate~ (sometimes I wish writing these posts can be automated as well.)

Let’s get into it.

What is CI/CD?

CI/CD is short for Continuous Integration and Continuous Delivery. In general terms, it encompasses concepts of combining, testing, and pushing out deliverables in a quick and reliable manner¹.

The CI part is related to checking, testing, and combining the work of the development team. It automates the process of integration, and in turn, drives the team to commit smaller scale changes.

The CD part extends the previous one. Once the newly updated codebase is tested and combined, this part of the automation will then deliver the code to a deploy environment. The deploy environment can range from dev environment, staging, testing, and production. Having the CD part implemented helps a lot with deployment.

source: codilime

Why use CI/CD?

In the case of our project, everytime we push some changes there are a bunch of steps we need to complete. We need to run the test for the whole codebase (because likely the dev team only test for the new features in their local environment). This is to make sure nothing from previous changes is broken and everything is in order. We also need to hook the updated codebase to SonarQube for profiling. Lastly, because we’re developing a mobile app, we need to generate an apk for every new release.

Now, imagine doing these steps manually everytime you push to remote repository.

What a nightmare.

The good news is, you don’t have to. Well, only if you applied CI/CD to your project (which we did. Since the very beginning).

Another way to say it is, we want to use CI/CD to reduce the amount of manual work needed to be done by the dev team (so they can focus on coding or fixing things around the codebase). With CI/CD, human intervention is no longer needed after the developer pressed enter. Everything will be taken care of automatically by the system.

How to CI/CD?

Here’s how we did CI/CD for Ajaib on DEX. Most of it was taken care of in the beginning of the first sprint, so I’ll try to recall the gist what we did back then.

The Sketching Phase

Before we do anything crazy, we need to note down what we actually need to be done. What do we need to automate?

In our case, we need these things to be taken care of automatically.

• Entire codebase test to get overall code coverage
• Hook codebase to SonarQube
• Build and generate APK for new releases

The Scripting Phase

After we know what needs to be automated, we can move on to writing the script. This is arguably the most manual labor you’ll do for this entire process. Yet most of the script code wouldn’t need to be typed from scratch. You’ll likely find someone else’s CI/CD script file ready to copy-and-paste.

Because we’re using Gitlab CSUI, we use gitlab-ci.yml for our script. First we need to define the stages and image.

image: node:lts-alpine
cache:
  key: ${CI_COMMIT_REF_SLUG}
  paths:
    - ~/.npm

stages:
  - test
  - build
  - code-quality

Thereafter, we gotta define what to do in each of the stages. Below is the test stage defined. This stage is going to be executed everytime a dev team member pushes to any branch. It will also update the coverage for said branch.

test:
  coverage: '/All files[^|]*\|[^|]*\s+([\d\.]+)/'
  stage: test
  script:
    - npm ci --prefer-offline --no-audit
    - npm test
  cache:
    key:
      files:
        - package-lock.json
    paths:
      - node_modules/

Next up is building APK. My team member pointed that we don’t need to build APK everytime we push. Therefore, the script is set such that it only builds one once we merge to staging or master, or when someone push a commit with the tag [BETA]. This way, we wont waste precious runner time in every pipeline². This can be achieved by specifying with the only keyword.

Build APK:
  stage: build
  dependencies:
    - test
  only:
    - staging
    - master

only:
    variables:
      - $CI_COMMIT_MESSAGE =~ /\[BETA]/

Lastly, we want to plug the codebase to a sonar scanner. SonarQube is a code-supervising tool to analyze our codebase. It gives us information like code smells, bugs, and a more precise code coverage.

The CI script for this stage has generally the same structure as the stages that comes before it. The only difference is the script executed, which was provided by our TAs.

And such, our CI script is done.

The Sit Back Phase

The only thing left to do is to push this script to a gitlab repo and let it do its thing. At this point, everyone in the dev team can sit back and watch the pipeline runner handle the testing, building, scanning, and deploying the updated codebase. After everything is executed, the feedback we get will be a red or a green pipeline~

TL;DR

• Practice CI/CD. It saves you time and hassle
• It's good for fast delivery
• There’s really no reason not to do it

That’s all for this one. Somehow I kept it short for once 😆

See you on the next one~