🔥 CI CD 적용기 with release 자동화 🔥

CI

Codecov + Jest 적용

typescript + jest codecov 적용 사전 테스트

도입 배경

그룹 프로젝트에서 애자일 방법론을 적용했기 때문에 앞으로 release가 최소 2회 남아있었다. 그래서 테스트 코드 coverage에 대한 검증을 하고 싶었다.

codecov는 PR Review를 진행할 때마다 _해당 PR이 code coverage를 얼마나 만족했는지 시각적으로 확인_할 수 있다는 점이 가장 매력적이었던 것 같다.

애자일 방법론을 적용하는 우리 팀의 test code coverage를 PR마다 시각적으로 확인함으로써, 유효한 테스트 코드를 작성했는지, 목표하는 만큼 테스트 코드를 적절한 범위로 잘 적용했는지 점검하려고 했다.

다만, 현재 인터넷에 나와 있는 많은 정보들이 v1에 맞추어있지만, v3과는 조금 차이가 있는 것 같아 혼란을 겪긴 했었다..

현재는 v1이 deprecated되어, v3을 사용하였다.

• 위에 사전 테스트한 결과를 참고하여 진행하되, 현재 OAO Project에서는 Client 파일에 알고리즘 테스트 코드가 들어가기 때문에 디렉토리를 바꾸어서 작업함.

  • client 디렉토리에 yarn이 설치되어 있기 때문에 cd client를 해줘야 한다.

• 또한, github actions yml 파일에 paths: client/**를 추가해서 클라이언트단 소스가 변경될 때만 돌아가도록 만들었다. (클라이언트 파일만 Test 대상이기 때문)

CD

yarn+express docker 적용 테스트

도커 + 자동배포 적용 배경

변경점이 생길 때마다 서버를 재구성하는 것은 너무 힘든 일이었다.. 추가로, 로컬에서는 잘 되는데, 서버로 올리면 잘 안 되는 경우가 생겨서 이에 대한 해소 방안도 필요했다. 이와 더불어, 개발 서버와 release 서버를 분리하게 되면서 모든 서버에 설정을 넣는 것은 비효율적이라 생각했다.

요약하자면, 다양한 환경(local, dev, release)에서의 어플리케이션을 효율적으로 관리할 수 있고, 이에 따라 발생할 수 있는 side effect 방지할 수 있기 때문이다!

FrontEnd 도커 설정

• /dist에 번들링된 index.html을 뿌려줌

깨달은 점

• docker 실행 시 host post:container server port를 매핑해야된다는 것을 알게 되었다.

docker run -d -p [내 local port]:[container에서 켜져있는 port] ghcr.io/kumsil1006/oao:latest

Docker pull & run

docker pull ghcr.io/kumsil1006/oao:oao-client
docker run -d -p 8080:3000 ghcr.io/kumsil1006/oao:oao-client

BackEnd 도커 설정

1. github actions에서 ts build

2. Dockerfile에서 build된 파일 copy 및 run

3. backend에 실행되어 있는 express 서버를 확인할 수 있다.

NGINX 도커 설정

• proxy용 서버 사용
• /: frontend, /api: backend로 프록시

Docker Compose 설정

• docker compose는 pull 받은 container만 compose를 다시 해준다.
• 따라서, client, server yml에 각각 변경점이 생겼을 때 빌드 후 pull하도록 설정하여 pull받은 컨테이너만 update하도록 설정했다.
• 이로 인해, client단 소스가 변경되었을 때는 client container만, server 소스가 변경되었을 때는 server container만 pull 하여 docker compose 부하를 줄이고자 했다. 추가로, github workflow yml file을 분리했기 때문에 실행하는 빌드&배포 부하와 배포로 인한 서버 중단과 이로 인해 일어나는 문제(세션, memory db 휘발)를 최소화하고자 했다.

client node_modules caching

• node_modules에 변경이 없는데도 불구하고 매번 yarn install을 하면 비효율적이다. 그렇기때문에 marketplace에 있는 cache action을 이용해 caching해주기로 했다
• nnode_modules에 대한 cache 검사를 한 후 모듈에 변한 것이 있다면 yarn install을 실행해주고, 변화가 없다면 그 다음 step으로 넘어간다.

결과물

backend

frontend

Github Action 수행시 slack에 알림주기

• 우리 프로젝트에선... main과 release에
  • client source에 변화가 있는 PR이 올라가면 code coverage Action이 수행된다.
  • client/server source 변화가 있는 push가 일어나면 CD Action이 수행된다.
• 이 Action들에 대해 매번 성공/실패를 보기 위해서는 Actions에 들어가서 확인해야하는 번거로움이 있었다. 그렇기때문에 slack에 이런 Action들이 수행되면 메세지를 보내주는 Action을 만들기로 하였다.
• 카카오웹툰은 GitHub Actions를 어떻게 사용하고 있을까? 글의 Composite Action 만들어보기를 참고하면 쉽게 Action을 만들 수 있다.

결과물

release branch 분리하기

github registry

dev

1. oao-dev-client
2. oao-dev-server
3. oao-dev-proxy

release

1. oao-client
2. oao-server
3. oao-proxy

github release 및 release note 작성 자동화

기능 설명

• release branch에 PR 날아갈 때마다 release되도록 설정
• body에 changelog를 추가해서 변경점을 추적해준다. (꿀기능)

도입 배경

• release 버전을 매번 수동으로 관리하기 어렵따!
• github registry의 이미지 버전을 tag로 관리하는데, 자동으로 버전이 라벨링되고 release 시 version up을 해줬으면 좋겠다!
• git release 시 변경점을 모두 기록해주고, 기능 추가(feat)인지, 버그 수정(fix)인 지에 대한 release note도 자동으로 생성해주다니..!! 이 기능을 사용하지 않을 이유가 없겠군!

고민들

• server, client의 스크립트에 각각 Release를 넣으면, client, server가 모두 배포되는 상황에 version up이 두 번 일어날 것 같다. 이렇게 버전 관리를 하는 것이 과연 맞을까에 대한 고민들.!

  • server, client가 모두 한 repository에서 관리되고 있고, 현재 계획상 release를 하면 기능 단위로 배포하기 때문에, server, client가 한 번에 올라갈 것이다. (hotfix 제외)

• 버전 관리 up 시 latest release를 기준으로 version update를 해주는데, 이 기능이 너무 좋아보였다..!!

  • 추후에 minor update를 할 때 스크립트를 가다듬으면 버전 관리를 더 잘 할 수 있을 것 같다.
  • 다만, release 이후 hotfix를 한다면 버전 관리를 어떻게 하면 좋을지 고민이다. (minor 배포, major 배포, hotfix 등 좀 더 세세한 작업들은 오히려 수동으로 하는 게 낫지 않을까.. 라는 생각이 들었다. 공식문서를 보면서 좀 더 잘 만들 수 있을 것 같다.)

• 추가 고민거리 및 피드백

  • 1차 release 이후 조사 예정

name: Release Github Application Version
on:
  pull_request:
    branches:
      - release

jobs:
  release-application:
    runs-on: ubuntu-latest
    steps:
      - name: Github Release 최신 tag 받아오기
        id: tag_version
        uses: mathieudutour/[email protected]
        with:
          github_token: ${{ secrets.GITHUB_TOKEN }}

      - name: GitHub project release 업데이트
        uses: ncipollo/release-action@v1
        with:
          tag: ${{ steps.tag_version.outputs.new_tag }}
          name: Release ${{ steps.tag_version.outputs.new_tag }}
          body: ${{ steps.tag_version.outputs.changelog }}