[Imhere 개발일지 #2] github action을 이용한 S3 배포, cloudfront, 버전관리 자동화

김유진·2023년 5월 29일
0

React

목록 보기
62/64
post-thumbnail

이번에 Imhere을 버전 2로 배포했고, 사실 버전관리를 하고 싶었으나 나중에 알아봐야지~ 히힛 하고 미뤄놨던 것을 제대로 마무리하고싶어서 공부하는김에 이 글을 쓰게 되었다.
다음에 과제 검사 기능까지 추가하게 되면 버전3으로 배포하게 될것 같아서 미리 버전관리를 하는 것이 좋을 것이라고 생각이 들었다. 🥸

진호님의 버전에 대한 리뷰!이다. 감사하게도 참고할 수 있는 깃 플로우 관리 전략에 대하여 다룬 블로그 링크 글도 넘겨주셔서 수월하게 공부할 수 있었다. 항상 무한 감사드리는 🙏

버전 관리

먼저 버전은 세 자리로 나누어서 많이들 이루어진다.

xxx.xxx.xxx
  • 앞의 자리 (major) : 호환이 안 되는 변경 => 구조 자체가 변화되어 큰 변화가 있을 경우
  • 중간 자리 (minor) : 호환이 가능한 변경 => 기능이 추가됨, 컴포넌트 추가, 함수 추가 등 이전의 버전에서 몇가지 기능이 추가로 붙을 경우
  • 맨 뒷 자리 (etc) : 버그 수정, 약간의 디자인 변경, 사소한 변동사항

이렇게 버전을 관리할 수 있고, 이번에 새롭게 디자인이 바뀐 Imhere는 2버전이고
og와 SEO, 회원가입 관련한 자잘한 버그들을 수정해서 배포하게 될 버전은 2.0.1버전이라고 할 수 있겠다. 그럼 이번에 내가 배포하게 될 버전을 알게 되었다.

기존 배포 방식?

기존 배포 방식은 아래와 같다. AWS S3로 배포를 진행하고 있었으며...IAM을 이용하여 AWS 리소스에 접근할 수 있는 계정을 생성한 이후 S3에 정적 파일을 업로드한 것이다.
이후 CloudFront를 통하여 CDN 역할을 할 수 있게 해 주는 것인데, CDN은 Content Delivery Network / Content Distribution Network의 줄임말로 저장된 정적 파일 (S3)를 어디스든 빠르게 이용할 수 있도록 한다. 기본적으로 캐싱을 해주기 때문에 배포를 해도 어떤 구역은 새로운 버전 전을 받아볼 수 있는데 이 때에는 캐싱 무효화 작업을 해야 한다.

배포하기 불편해 엉엉

배포 자체 과정은 쉽다고 할 수있으나, dev브랜치에 푸시한 다음.. 일일이 빌드를 진행해서 aws계정 인증하고 .. S3파일 올리고.. 캐싱 무효화하고 정말 왕답답이었다.
이걸 내가 다 하나하나 수동으로 배포할 때마다 해야 한다는 게 비효율적이고 말이 안된다고 생각했다 .😅 그러니 이 김에 배포 자동화를 해보면 어떨까? 라는 생각이 들었다.

배포 자동화 선택

배포 자동화에서 내가 사용할 것은 당연히 github action !!
깃헙액션으로 release브랜치에 새로운 내용이 푸시될 경우 자동으로 빌드해서 S3에 업로드하고 cloudfront에 자동으로 연동될 수 있도록 해보자.

배포 자동화

IAM 권한 수정

먼저 IAM의 사용자 권한을 수정해주어야 한다. AWS 홈피에 들어가서 권한을 수정해주쟈~
CloudFrontFullAccess, AmazonS3FullAccess 권한이 있으면 된다. 자, 이제 IAM 계정에 대한 Access Key IDSecret Access 정보를 손에 쥐고 있으니까 git workflow 설정을 해봅시동..

workflow 파일 작성

내가 원하는 것은 태그 생성 + Release 생성 자동화였다.
deploy 브랜치에다가 push를 할 때마다, 배포가 자동적으로 이루어져 S3 버킷에 정적 파일이 업로드되고, 해당 버전에 대한 버전을 태그로 관리하며 자동적으로 릴리즈 버전까지 latest로 설정되어 공개해주는 것이다. 그렇기 때문에 그에 대한 부분을 신경쓰면서 yml파일을 작성하려고 하였다.

브랜치 관리, 태그 생성

먼저 workflow를 만들기 위해서 .github/workflows 경로에 워크플로우에 대한 yml파일을 작성한다.
그리고 아래와 같이 작성한다.

name: Build & Deploy Imhere
on:
  push:
    branches: [deploy]

jobs:
  build:
    runs-on: ubuntu-latest
    permissions:
      contents: write
    steps:
      - name: Checkout source code
        uses: actions/checkout@master
      
      - name: Get version
        id: tag_version
        uses: mathieudutour/github-tag-action@v6.1
        with:
          github_token: ${{ secrets.GITHUB_TOKEN }}

먼저 가장 최신의 태그 버전을 가져와야 하기 때문에 mathieudutour라는 github action 라이브러리를 이용하여 태그를 관리할 수 있도록 하였다. 이 때 GITHUB TOKEN을 이용하는데 이는 자동으로 생성되기 때문에 따로 레포지토리 secrets에 추가하지 않아도 된다.
그리고 deploy 브랜치에 푸시될때마다 배포가 이루어져야 하므로 action을 수행할 트리거가 되는 브랜치도 정해주었다.

릴리즈 자동 생성

- name: Create Release
        uses: ncipollo/release-action@v1
        with:
          tag: ${{ steps.tag_version.outputs.new_tag }}
          name: Imhere-${{ steps.tag_version.outputs.new_tag }}
          body: ${{ steps.tag_version.outputs.changelog }}
          owner: "eugene028"

      - name: Install Dependencies
        run : yarn

짜잔 이제 tag를 자동적으로 생성하였기 때문에 그에 맞춰 자동적으로 릴리즈를 해 주면 된다. 릴리즈 관련된 라이브러리를 ncipollo를 사용하였다.
여기서 name 프로퍼티는 앞에 Imhere-을 붙이고 뒤에는 최신 버전 태그가 붙을 수 있도록 한다.

그럼 이렇게 릴리즈 버전이 action을 돌릴 때마다 자동으로 보여지게 된다.
그리고 changelog에 대한 부분을 바꿀 수 있는데,

  • fix
  • feature
  • pref

이 세 부분을 커밋 메세지의 헤드로 작성하게 되면 아래와 같이 자동적으로 body로 내용이 채워지게 된다.

따로 릴리즈 관련 문서를 작성하지 않아도 알아서 커밋 헤드에 따라서 관리를 해 주므로 매우 편리하다.
물론 action info를 더욱 추가하여 더욱 많은 내용을 관리할 수 있다. discussion 부분 읽어보니까 아예 배포를 할 때마다 md 파일을 추가하여 버전에 대한 상세 설명을 마크다운으로 관리하는 분도 계셨다. 시간이 되면 마크다운 파일도 잘 꾸며서 올려보아야 겠다!

AWS S3에 업로드

- name: Build
   run: CI='' npm run build

- name: Deploy
  env:
      AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
      AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
      AWS_DEFAULT_REGION: ap-northeast-2
  run:
      aws s3 sync ./build s3://imhere-client

따단. 이렇게 작성하면 자동으로 정적 파일을 버킷에 업로드해준다. 해당 레포지토리의 settings로 들어가 secrets 키로 IAM에 대한 ACCESS KEY 관련 세팅을 해 줘야 한다.
이 때 마주쳤던 에러가 두 가지 있는데, 이 부분을 글을 읽는 사람들은 빠트리지 않고 꼭 넣기를..

run: CI='' npm run build

자꾸 build를 할 때 아래와 같은 이유로 실패한다.

이는 warnings는 Error로 처리하는 라이브러리가 있기 때문에 그런 것이므로, CI 세팅을 true가 아닌 다른 값으로 바꿔 주면 해결할 수 있다.
그래서 위와 같은 액션 스크립트 CI='' 를 추가하여 에러를 해결할 수 있었다.

AWS_DEFAULT_REGION: ap-northeast-2

이 스크립트는 <botocore.awsrequest.AWSRequest object at >....는 에러가 빌드 시에 뜨길레 어던 에러인지 찾아봤더니!! AWS 배포에 대한 지역을 따로 설정해주지 않아서 발생한 에러였다. 그렇기 때문에 default region을 추가해줬더니 바로 해결 가능했다! :)

결과물


따단 ~ github action을 돌리고 나니까 S3 버킷에 정적 파일이 자동으로 올라와 있는 것을 확인할 수 있었다. ㅎㅎ

이제 cloudfront 무효화면 해주면 완전 배포 끝!!!!!!
이렇게 해서 멋지게 배포된 우리 Imhere v2. 회원가입하고 함 둘러보세용! (이번에 og 이미지랑 description도 추가했지롱..)
https://imhere.im/

1개의 댓글

comment-user-thumbnail
2023년 9월 26일

안녕하세요! main에 푸시할 경우 자동으로 태그를 달도록 github action을 만들려고 하는데, 혹시 어떻게 태그 version을 지정하셨나요? 1.0.1 이렇게 지정하고 싶어도 main에 push할 경우 tag version이 자동으로 0.0.1, 다음은 0.0.2 이런식으로 지정되더라구요😂
글에서 v2.0.5이런식으로 태그를 다셨길래 여쭤봅니다..!!

답글 달기