Skip to main content

Unit 2 - Continuous Integration with GitLab CI

About 3 minGitlabcrashcourseyoutubefreecodecampvdespagitlabyamlcicdcicd

Unit 2 - Continuous Integration with GitLab CI κ΄€λ ¨

2.1 Unit overview

  • we will start working on a simple website project
  • we want to automate any of the manual steps required for integrating the changes of multiple developers
  • we will create a pipeline that will build and test the software we are creating

2.2 Your first GitLab project

  • we will try to automate the build and deployment of a simple website project build with JavaScript using the React framework
  • forking allows making a copy of a project
  • the key to automation is to be familiar with the CLI tools we plan to use in GitLab CI

πŸ“š Resources

2.3 Building the project

  • most software projects have a build step where code is compiled or prepared for production-use
  • yarn is a Node.js package manager that helps with managing the project by running scripts and installing dependencies
  • for a Node.js project, the node_modules folder contains all project dependencies
  • project dependencies are installed using yarn install but are NOT stored in the Git repository
  • it is really a bad idea to store project dependencies in the code repository
  • image tags that contain alpine or slim are smaller in size as they use a lightweight Linux distribution
Pipeline after this lecture .gitlab-ci.yml
build website:
  image: node:16-alpine
  script:
    - yarn install
    - yarn build

πŸ“š Resources

2.4 Assignment

  • Create a job to verify that the build folder contains a file named index.html
  • Create another job that runs the project unit tests using the command yarn test

2.5 Assignment solution

My solution to the assignment .gitlab-ci.yml
stages:
  - build
  - test

build website:
image: node:16-alpine
stage: build
script:
  - yarn install
  - yarn build
artifacts:
  paths:
    - build

test website:
  image: alpine
  stage: test
  script:
    - test -f build/index.html

unit tests:
  image: node:16-alpine
  stage: test
  script:
    - yarn install
    - yarn test

2.6 How do we integrate changes?

  • we use Git to keep track of code changes
  • we need to ensure we don't break the main pipeline

Git for Gitlab

2.7 Merge requests

  • we need to ensure that the chances of breaking the main branch are reduced
  • here are some project settings for working with Merge Requests that I recommend:
    • Go to [Settings] > [Merge requests]
    • Merge method > select Fast-forward merge
    • Squash commits when merging > select Encourage
    • Merge checks > check Pipelines must succeed
  • protect the master by allowing changes only through a merge request:
    • [Settings] > [Repository] > Branch main > Allowed to push - select No one
Pipeline after this lecture .gitlab-ci.yml

stages:
  - .pre
  - build
  - test

build website:
  image: node:16-alpine
  stage: build
  script:
    - yarn install
    - yarn build
  artifacts:
    paths:
      - build

linter:
  image: node:16-alpine
  stage: .pre
  script:
    - yarn install
    - yarn lint

test website:
  image: alpine
  stage: test
  script:
    - test -f build/index.html

unit tests:
  image: node:16-alpine
  stage: .pre
  script:
    - yarn install
    - yarn test

2.8 Code review

  • merge requests are often used to review the work before merging it
  • merge requests allow us to document why a specific change was made
  • other people on the team can review the changes and share their feedback by commenting
  • if you still need to make changes from the merge request, you can open the branch using the Web IDE

πŸ“š Resources

2.9 Integration tests

  • before we ship the final product, we try to test it to see if it works
  • testing is done of various levels but high-level tests typically include integration and acceptance tests
  • we use cURL to create an HTTP call to the website
Pipeline after this lecture .gitlab-ci.yml
stages:
  - .pre
  - build
  - test

build website:
  image: node:16-alpine
  stage: build
  script:
    - yarn install
    - yarn build
  artifacts:
    paths:
      - build

linter:
  image: node:16-alpine
  stage: .pre
  script:
    - yarn install
    - yarn lint

test website:
  image: node:16-alpine
  stage: test
  script:
    - yarn global add serve
    - apk add curl
    - serve -s build &
    - sleep 10
    - curl http://localhost:3000 | grep "React App"

unit tests:
  image: node:16-alpine
  stage: .pre
  script:
    - yarn install
    - yarn test

2.10 How to structure a pipeline

  • our current pipeline structure is just an example, not a rule
  • there are a few principles to consider

principle #1: Fail fast

  • we want to ensure that the most common reasons why a pipeline would fail are detected early
  • put jobs of the same size in the same stage

principle #2: Job dependencies

  • you need to understand the dependencies between the jobs
  • example: you can't test what was not already built yet
  • if jobs have dependencies between them, they need to be in distinct stages
이찬희 (MarkiiimarK)
Never Stop Learning.