상세 컨텐츠

본문 제목

[TIL] 2024.03.15 git actions CI/CD TEST

카테고리 없음

by 재호링 2024. 3. 16. 01:01

본문

name: Nestjs CI

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  build:
    runs-on: ubuntu-latest

    strategy:
      fail-fast: false
      matrix:
        node-version: [16.x, 18.x, 20.x]

    steps:
      - uses: actions/checkout@v2
      - name: Use Node.js ${{ matrix.node-version }}
        uses: actions/setup-node@v2
        with:
          node-version: ${{ matrix.node-version }}
      - name: Install dependencies
        run: npm ci
      - name: Run lint
        run: npm run lint
      - name: Run tests
        run: npm test

 

name은 깃허브 이름

jobs: 는 build라는 잡 하나

matrix: build는 우리가 세팅한 이름

여러가지 단계를 가진다는 steps:

버전을 여러개 테스트하는 이유는

빌드라는 잡 하위의 strategy 덕분에

3가지의 jobs를 다 돌리겠다는 의미

 

하나의 jobs는 여러개의 steps을 가질 수 있음

위 코드에서는 정확하게 4개를 가지고 있다

 

setupjob

run actions/checkout

usenode 몇버전쓰는지 알려주는 것 법칙임 문법 구조라고 보면 됨

initial dependencies 다섯개까지 볼 수 있다 실행할 브랜치로 가야된다

event는 on: 하위가 담당한다

특정 브랜치로 push하거나 PR을하거나

 

굉장히 유용한 특정 시간대에 반복하는 Cron

 

여러가지 잡으로 구성이 되는데 on event가 발생했을 때

jobs를 순서대로 실행

선 후행 관계로 만들어서 선행 실패 여부에 따라 다르게 처리할 수 있음

이 steps 안에 들어가는 실질적으로 일어나는 행위를 action이라고 부름

워크플로우 단위에서 가장 작은 단위

 

runs-on: ubuntu-latest

는 가동할 컴퓨터가 필요한 뜻

명시한 ubuntu-latest 는 여기서 돌리겠다라는 뜻

 

on: 은 트리거를 명시함

on이 발생했을 때 workflow가 돌아가게끔

main이 push 됐을 때 workflow가 돌아간다

PR도 마찬가지

 

lint는 prittier의 상위버전

package.json을 보면 lint라는게 있다

카멜케이스라는 신택스를 안달고 _ 스네이크 케이스를 쓴다거나

이런걸 검증하는걸 lint 단계다

린팅을 하는 이유는 린팅시 코딩 규약을 맞추기위함

코딩컨벤션이라고함

그래서 린트 단계랑 test단계를 나눈것이다

 

CI/CD 세계에서 이 job을 파이프라인이라고 말한다

CI를 위한 ㄹ파이프라인을 직접 구축한거다

 

 

이제 CD를 해보자 자동배포,, 드가자

 

커널이 진주라고해서 쉘이라고 부른다

.sh 쉘의 약자 쉘 스크립트를 작성해서 run.sh를 입력

 

 

CI/CD 파이프라인을 3개 구성함

린팅은 문법적 오류를 체크했음

다중버전으로 테스트했음

이게 파이프라인이고 CI/CD의 흐름

testcode가 틀리면 배포가 안된다

두번째 파이프라인에서 터진다

테스트 커버리지가 80 이상이여야만

배포 가능하게 만들 수 있음

이런식으로 CI/CD를 쓸 수 있음

 

이걸 바탕으로 elastic Beanstalk

 

aws만 써서 aws 위주로 배포 환경을 다르게 할 수 있음

s3에 올리고 codeDeploy를 만들게

이렇게하면 최초세팅할 필요 없고 인스턴스가 자동으로

우리가 가진 압축파일로 돌아가게 할 수 있다

 

젠킨스도 이 흐름과 다르지 않다

도커라는걸 해서 젠킨스 컨테이너를 써보면 좋다

자바 기반으로 돌아가서 이것저것 건드려보는걸 추천

 

우리가 배포하는 순간 서비스가 멈춘다.

그래서 어떻게하면 멈추지 않고 배포가 가능할까?

이게 무중단 배포인데 롤백이라던지 롤오버를

살펴보는게 좋다. 로깅에 대한 관점 어떻게 서버가 죽었고

그런걸 추적이 가능해진다

 

서버가 살아있는지 체크하는건 모니터링에 대해

필요한건 ㅁ뭔지

 

프로비저닝은 요청이 터졌을때 스케일업 스케일 아웃 이 반대를 해줄 수 있음

k8s (쿠버네티스)를 쓸 때는 어떤 흐름을 쓰는지

코드변경감지

린팅엔컴파일체크

테스트체크

이미지빌드체크

이미지레지스트리에푸시

쿠버네티스에배포

배포로라웃

모니터링 및 롤백

알림 및 보고

기타 등

 

CI먼저하기

 

일단 주말에 다시 수정할거임