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

CI

Codecov + Jest 적용

typescript + jest codecov 적용 사전 테스트

도입 배경

그룹 프로젝트에서 TDD를 적용했고, 애자일 방법론을 채택했기 때문에 앞으로 release가 최소 2회 남아있었다. 그래서 기능 수정/리팩토링 시 보다 견고한 프로젝트 환경을 구성하고 싶었다.

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

다시 말해, 최소한 TDD를 적용한 core 알고리즘에 개발자가 할 수 있는 실수를 방지하고, release된 서비스가 보다 견고할 수 있도록 도입하게 되었다.

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

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

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

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

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

CD

yarn+express docker 적용 테스트

도커 + 자동배포 적용 배경

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

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를 추가해서 변경점을 추적해준다. (꿀기능)

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 }}