[Day 6] JS in Pipeline (6): CI/CD pipeline (1)


The goal of this series is to introduce some best practices in the local development environment and create a CI/CD pipeline for NodeJS applications.

GitHub repo for this article series: https://github.com/jeanycyang/js-in-pipeline
In this article, we will create a CI/CD pipeline and focus on the CI process.


If you have read from the first article to this article, thank you for reading the article series — finally, we are going to set up our CI/CD pipeline with confidence!

In this article series, we put our Git repository on GitHub and use TravisCI as our CI/CD server/platform.

What is CI/CD?

Continuous Integration (CI)

Continuous integration (CI) is the practice of automating the integration of code changes from multiple contributors into a single software project. The CI process is comprised of automatic tools that assert the new code’s correctness before integration.
https://www.atlassian.com/continuous-delivery/continuous-integration

Take our code for example. We want to make sure everything goes well, and this process should be done automatically by machines. It should never be manually as humans are error-prone.

We have two mandatory checks — unit tests and linting. You can add more checks, such as integration tests and npm audit.

You can build your code in the CI process. For example, if you use babel or TypeScript, your code then needs to be compiled.

CI process contains every step you need to do before the deployment.

A more complicated example: You have a TypeScript project and it is dockerized. Then, the CI process would look like:

1. npm install
2. npm audit # to check if any of your dependencies is vulnerable
3. npm run lint
3. npm test
4. npm run build # compile TS to JS
5. npm run integration-test
6. docker build -t my-server:${GIT_COMMIT_HASH} .
7. docker push my-server:${GIT_COMMIT_HASH}

Note that some steps can be run in parallel, e.g. npm run lint and npm test in this case.

If any of these steps fails, this build also fails.

Continuous Delivery/Continuous Deployment (CD)

CD is either Continuous Delivery or Continuous Deployment. They are two different practices. You can find more information in this article: https://www.atlassian.com/continuous-delivery/principles/continuous-integration-vs-delivery-vs-deployment

The “CD” in our CI/CD pipeline is like Continuous Deployment more. The goal of Continuous Deployment is to deploy our code changes to the wanted environment (e.g. test, stage, production) automatically.

For example,

8. terraform plan
9. terraform apply # our terraform file contains a ECS task which uses our new-built Docker image

(Terraform is an Infrastructure as Code tool. You can provision your cloud infrastructure using declarative configurations.)

Get Our Feet Wet

Let’s create our CI/CD pipeline.

You can sign up/sign in TravisCI with your GitHub account. For public GitHub repositories, you can use TravisCI for free.

Find your repository on this page: https://travis-ci.org/account/repositories and switch on. It automatically integrates your repository with TravisCI. Don’t panic on the settings page —some of them are really advanced so just ignore them now.

Create .travis.yml in the project directory.

# ${PROJECT_DIRECTORY}/.travis.yml
language: node_js
node_js:
 - 10.19.0
cache: npm
script:
  - npm audit
  - npm run lint
  - npm test

First, specify the language and the version. You can list multiple NodeJS versions if needed — but in our case, we use Docker and the NodeJS version is always 10.19.0.

TravisCI will install NodeJS and install npm packages automatically so we don’t need to list them in scripts .

cache: npm explicitly tells TravisCI to cache the npm install. Generally speaking, dependency installation takes a long time. Next time the server runs a build, if there is no dependency change, it will use the cache and save the installation time.

script tells TravisCI what we want to do. We run npm audit to check if there is any vulnerability in the dependencies; if so, it would exit with non-zero and fail the build. Later, npm run lint and npm test.

For more information, you can read the TravisCI documentation for NodeJS: https://docs.travis-ci.com/user/languages/javascript-with-nodejs/.
Let’s push the latest commit to GitHub. A build on TravisCI should automatically start!

You can view it on https://travis-ci.org/jeanycyang/js-in-pipeline/builds/656359982.

This is our first CI/CD pipeline!

Alternatives

There are several alternatives such as drone, CircleCI, Jenkins and they all have their own killer-features; nonetheless, the idea of CI/CD pipeline matters the most. Choose any of them you like and then focus on what steps you want to add.


In the next article — the final article of this series, we will finish our CI/CD pipeline — the CD part!


Useful Links/References

#devops #nodejs #Node #ci cd #CI/CD #pipeline #travisCI #travis-ci
JS in Pipeline
The goal of this series is to introduce some best practices in the local development environment and create a CI/CD pipeline for NodeJS appl






Related Posts

質數判斷演算法

質數判斷演算法

[ Day 03 ] 用 Puppeteer 來做自動化機器人吧 (二) : 基礎篇

[ Day 03 ] 用 Puppeteer 來做自動化機器人吧 (二) : 基礎篇

每日心得筆記 2020-06-22(一)

每日心得筆記 2020-06-22(一)

[Day 7] JS in Pipeline (7): CI/CD pipeline (2) (Fin.)

[Day 7] JS in Pipeline (7): CI/CD pipeline (2) (Fin.)

React Native in 24 Hours

React Native in 24 Hours

Day02:從判斷式看 bytecode

Day02:從判斷式看 bytecode



Comments