Github Actions, S3, CloudFront OAC로 CICD 전략 구축하기 (3) - 배포 브랜치 전략에 맞는 CICD yml작성하기

그럼 이걸 활용해서 yml을 만들어보자.

 

Github Actions

Github Actions는 github에서 제공하는 CICD 툴으로써, 코드 저장소에 어떤 이벤트가 발생했을때 특정 작업을 일어나게 하거나 주기적으로 작업을 반복 실행시키는 일을해준다.

 

이에 따라 브랜치마다 다른 일을 할 수 있도록 처리해줄 수 있다.

그럼 브랜치마다 어떻게 작동하게 만들지 전략을 수립해보자.

 

배포 브랜치 전략 수립하기

우리팀은 프론트엔드 코드와 백엔드 코드가 한 레포지토리에 있기때문에, 각 파트별 배포가 필요한 상황이었다.

https://github.com/boostcampwm2023/web05-AlgoITNi

GitHub - boostcampwm2023/web05-AlgoITNi: 동료와 함께 할 수 있는 플랫폼, 알고있니

 

그래서  git flow를 활용한 파트별로 분기하는 형태의 배포 전략을 수립했다.

dev에 작업이 완료된 경우, pull request를 통해 CI를 진행하고, release 브랜치에 push될때 CI/CD과정을 진행하도록 구성했다. 그림으로 그리면 아래와 같다.

yml작성하기

yml은 프로젝트루트에 .github/workflows내부에 작성하면된다.

CI만 하는 용도의 yml과 CI/CD를 모두 해줄 yml 두가지를 작성해줄 것이다.

 

dev 브랜치용 CI yml작성

브랜치 설정

FE/release, dev, main 브랜치에 풀리퀘스트가 작성될때 검사하면 머지되기전에 빌드가되는지 확인할 수 있다.

그래서 이렇게 작성했다.

name: frontEnd CI
on:
  pull_request:
    branches: [FE/release, dev, main]

CI환경 구성

jobs는 하나의 실행환경으로, 작업이 일어나는 단위이다.

ubuntu-22.04버전에서 node 18.16버전을 통해 CI를 진행할 것이다.

jobs:
  build-test-deploy:
    runs-on: ubuntu-22.04

    strategy:
      matrix:
        node-version: [18.16.0]

저장소에서 코드가져오기

github actions는 도커처럼 하나의 독립된 실행환경이라, 우리 저장소 코드 내용을 전혀 모른다.

그래서 저장소 코드를 가져와줘야하는데, 이때 미리 만들어진 이미지를 사용할 수 있다.

actions/checkout@v3라는 이미지를 사용하면 우리 저장소의 코드를 actions실행 환경에 가져올 수 있다.

    steps:
      - name: ✅ 코드 체크아웃
        uses: actions/checkout@v3

 

CI구성하기

테스트, 빌드 내용을 작성해주자. 

우리프로젝트는 프론트엔드와 백엔드가 같은 레포지토리에 있기때문에 /frontEnd로 working-directory를 설정해주었다.

또한, env파일이 github actions환경에는 없으므로, 이걸 github 레포지토리에서 secrets 객체를 가져와서 만들어주는 과정이 필요하다.

secrets에 들어가는 내용은 github 레포지토리 settings에서 넣어줄 수 있다.

      - name: ⬇️ 의존성 설치
        working-directory: ./frontEnd
        run: npm install

      - name: ✅ 유닛 테스트
        working-directory: ./frontEnd
        run: npm test

      - name: ⚙️ env 설정
        working-directory: ./frontEnd
        run: |
          touch .env.production
          echo "VITE_SOCKET_URL=${{secrets.VITE_SOCKET_URL}}" >> .env
          echo "VITE_API_URL=${{secrets.VITE_API_URL}}" >> .env
          echo "VITE_TURN_URL=${{secrets.VITE_TURN_URL}}" >> .env
          echo "VITE_TURN_USERNAME=${{secrets.VITE_TURN_USERNAME}}" >> .env
          echo "VITE_TURN_CREDENTIAL=${{secrets.VITE_TURN_CREDENTIAL}}" >> .env
          echo "VITE_STUN_URL=${{secrets.VITE_STUN_URL}}" >> .env
          echo "VITE_STUN_USERNAME=${{secrets.VITE_STUN_USERNAME}}" >> .env
          echo "VITE_STUN_CREDENTIAL=${{secrets.VITE_STUN_CREDENTIAL}}" >> .env
          echo "VITE_CHAT_URL=${{secrets.VITE_CHAT_URL}}" >> .env
          echo "VITE_CODE_RUNNING_SOCKET_URL=${{secrets.VITE_CODE_RUNNING_SOCKET_URL}}" >> .env

      - name: 📦 프로젝트 빌드
        working-directory: ./frontEnd
        run: npm run build

이러면 풀리퀘를 작성하면 테스트가 돌아간다!

 

전체 yml

name: frontEnd CI
on:
  pull_request:
    branches: [FE/release, dev, main]
jobs:
  build-test-deploy:
    runs-on: ubuntu-22.04

    strategy:
      matrix:
        node-version: [18.16.0]
    steps:
      - name: ✅ 코드 체크아웃
        uses: actions/checkout@v3

      - name: ⬇️ 의존성 설치
        working-directory: ./frontEnd
        run: npm install

      - name: ✅ 유닛 테스트
        working-directory: ./frontEnd
        run: npm test

      - name: ⚙️ env 설정
        working-directory: ./frontEnd
        run: |
          touch .env.production
          echo "VITE_SOCKET_URL=${{secrets.VITE_SOCKET_URL}}" >> .env
          echo "VITE_API_URL=${{secrets.VITE_API_URL}}" >> .env
          echo "VITE_TURN_URL=${{secrets.VITE_TURN_URL}}" >> .env
          echo "VITE_TURN_USERNAME=${{secrets.VITE_TURN_USERNAME}}" >> .env
          echo "VITE_TURN_CREDENTIAL=${{secrets.VITE_TURN_CREDENTIAL}}" >> .env
          echo "VITE_STUN_URL=${{secrets.VITE_STUN_URL}}" >> .env
          echo "VITE_STUN_USERNAME=${{secrets.VITE_STUN_USERNAME}}" >> .env
          echo "VITE_STUN_CREDENTIAL=${{secrets.VITE_STUN_CREDENTIAL}}" >> .env
          echo "VITE_CHAT_URL=${{secrets.VITE_CHAT_URL}}" >> .env
          echo "VITE_CODE_RUNNING_SOCKET_URL=${{secrets.VITE_CODE_RUNNING_SOCKET_URL}}" >> .env

      - name: 📦 프로젝트 빌드
        working-directory: ./frontEnd
        run: npm run build

 

release 브랜치용 CI/CD yml작성

환경 구성과 CI로직까지는 동일하다.

다만, actions실행 시점을 main과 release에 push할때로 설정해주자.

name: frontEnd CI/CD
on:
  push:
    branches: [FE/release, main]

S3업로드

actions 실행환경에서 빌드된 파일을 S3로 업로드시켜주자.

 

 

      - name: ⬆️ S3업로드
        working-directory: ./frontEnd
        env:
          AWS_ACCESS_KEY_ID: '${{secrets.AWS_ACCESS_KEY_ID}}'
          AWS_SECRET_ACCESS_KEY: '${{secrets.AWS_SECRET_ACCESS_KEY}}'
          AWS_DEFAULT_REGION: '${{secrets.AWS_DEFAULT_REGION}}'
        run: |
          aws s3 sync ./dist s3://버킷

빌드된 dist디렉터리를 s3버킷으로 동기화시켜주면된다.

 

CDN캐시 무효화

CloudFront는 edge server에 S3원본 데이터에 대한 캐시를 갖고있게 해준다. (이전게시글 참고)

따라서 원본데이터가 업데이트 되어도, 캐시를 업데이트 하지 않으면 사용자는 업데이트 되지 않은 이전 버전의 사이트를 보게 될 것이다.

그래서 edge server의 캐시를 무효화해주는 작업이 필요하다.

AWS Cli를 통해서 이 작업을 진행할 수 있다.

콘솔에서도 cloudfront배포의 무효화 탭을 통해 캐시 무효화가 가능하다.

 

이걸 활용해서 yml을 작성해주었다.

      - name: 🔄️ Cloudfront edge 로케이션에 대한 캐시 무효화
        env:
          AWS_ACCESS_KEY_ID: '${{secrets.AWS_ACCESS_KEY_ID}}'
          AWS_SECRET_ACCESS_KEY: '${{secrets.AWS_SECRET_ACCESS_KEY}}'
          AWS_DEFAULT_REGION: '${{secrets.AWS_DEFAULT_REGION}}'
        run: |
          aws cloudfront create-invalidation --distribution-id 클라우드프론트ID --paths "/*"

 

결론적으로 아래와 같은 CICD 구조를 갖게 되었다.

 

이렇게 하고 FE/release에 머지시키면...!

잘 작동하는 것을 볼 수 있다!