🔹 이번 포스팅은 Vercel과 GithubAction을 이용해 프론트엔드 배포를 자동화 하는 방법을 다루고 있습니다.
AI 기반 퀴즈 생성 및 학습 보조 웹서비스 QRAB의 개발이 마무리되는 단계에서..
이제 배포를 진행해보려고 한다!
AWS EC2, S3+CloudFront, Amplify, Netlify, Vercel 등 여러 선택지가 있었지만
쉽고 빠른 배포 + 비용를 고려했을 때 Vercel로 배포하기로 결정했다!
EC2나 S3+CloudFront는 프론트엔드 배포치고 고려해야 할 옵션들이 많았고,
페이지 수가 많은 경우에는 Netlify보다 Vercel이 더 최적이라는 글을 보았다.
Netlify와 Vercel의 차이점을 간략하게 정리하자면,
- Netlify
- 장점
- 배포 설정이 매우 쉽고 간편함
- HTTPS 지원 (SSL/TLS 기능)
- Github와 통합하여 CI/CD 구축 가능
- 다양한 플러그인 지원 - 단점
- 빌드 속도가 Vercel에 비해 느림
- 장점
- Vercel
- 장점
- 배포 설정이 매우 쉽고 간편함
- HTTPS 지원 (SSL/TLS 기능)
- Github와 통합하여 CI/CD 구축 가능
- 빠르고 효율적인 빌드 - 단점
- 깃허브 organization에 있는 레포지토리를 배포하기 위해서는 pro plan을 추가로 결제해야 함
- 제한된 플러그인 제공
- 장점
이외에도 다양한 장단점이 존재하지만, 팀 레포지토리를 개인 계정으로 fork 해오는 것은 크게 문제가 안 되었고 지금 당장은 다양한 플러그인을 사용할 필요도 없었기에 Vercel을 사용하기로 결정했다!
(사실 동아리에서 Vercel로 배포하는 법을 배웠는데 실제로 프로젝트에 직접 적용해보고 싶기도 했고, 프론트배포!! 하면 딱 떠오르는 기본 툴이 Vercel이었어서 기본은 알아야 한다고 생각했다..ㅎ)
+) AWS Amplify의 경우 Vercel만큼이나 간단하고, Github Action을 이용하지 않고도 CI/CD 구현이 가능하다는 것을 Vercel로 배포한 후에 알게 되었는데.. 나중에 프로젝트가 끝났을 때 Amplify로도 다시 한 번 재배포를 해보려고 한다.
🎈 배포 방법
step by step으로 하나씩 설명해보려고 한다.
(현재 github organization에 배포할 레포지토리가 있다고 가정하고 포스팅을 작성했습니다)
1. 우선 Vercel 웹사이트 접속
만약 회원가입이 되어있지 않다면 회원가입을 해야한다. (깃허브와 연동하여 사용할 수도 있다!)
2. Add new > Project 클릭
나는 이전에 배포를 했었기 때문에 하나의 프로젝트가 이미 생성되어 있다
3. 깃 레포지토리를 import 하면 된다.
이 때 주의할 점!
무료로 vercel을 사용하고 싶다면 organization 레포지토리에서 개인 레포지토리로 프로젝트를 fork 해야 한다!!
organization 레포지토리를 그대로 import하면 배포할 때 pro plan으로 전환하라는 메시지가 뜬다..
그럼 이런 의문이 들 수 있다. (내가 그랬다)
그럼 수정사항이 생겨 재배포를 해야할 때는 팀 레포지토리 말고 개인 레포지토리에서 PR을 해야 하나요??
=> Github Action을 이용해 organization 레포지토리에 PR을 날렸을 때 개인 계정으로 자동으로 동기화 되도록 할 수도 있으니 (뒤에 설명) 걱정 말고 개인 계정에 레포지토리를 fork 해도 된다!
4. 아래 화면이 보이면 세부 설정을 해준다.
- 프로젝트 이름 입력 : qrab-chih => 원하는 프로젝트 이름으로 작성해준다.
- Framework Preset : 사용중인 프레임워크 설정
- 나는 React를 Framework로 사용했기 때문에 Create React App으로 설정했는데, 사용한 프레임워크가 Vue, Angular, Next.js 등 다른 것이라면 그에 맞게 설정해주면 된다. - Root Directory : 소스코드가 위치한 디렉토리 선택 (이 디렉토리 내의 파일을 기반으로 프로젝트를 빌드&배포한다!)
- 나는 기본값인 현재 디렉토리 ./ 그대로 놔뒀는데, 만약 프로젝트의 package.json 파일이 루트 디렉토리가 아니라 하위 폴더에 있으면 해당 하위 폴더를 지정해야 한다. ex) frontend/ , qrab/ 등 - Build Command : 프로젝트를 빌드하기 위해 실행할 명령어 입력
- React 프로젝트라면 npm run build, next 프로젝트라면 next build 등 설정한 명령어에 맞게 작성해주면 된다. - Output Directory : 빌드된 결과물이 생성되는 디렉토리
- 프로젝트 루트 디렉토리에 생성되는 것이 일반적이다. ex) React의 경우 build, Next.js의 경우에는 SSR(서버사이드렌더링)을 지원하므로 이 설정이 필요하지 않다. - Install Command : 사용 중인 패키지 관리 도구에 따라 선택
- 만약 패키지 매니저로 yarn을 사용했다면 yarn install, npm을 사용했다면 npm install - Environment Variables : 배포 환경에서 사용되는 환경 변수
- 백엔드 서버 URL, API 키 값 등의 변수를 집어넣는다.
5. Deploy 버튼을 누르면 배포 완료!!
이제 Github Actions으로 CI/CD를 구축해 배포한 레포지토리에 배포 자동화 기능을 적용하자!
우선.. CI/CD 가 무엇인지부터 간단하게 살펴보자
- CI (Continuous Integration) : 지속적인 통합을 의미한다.
만약 팀 프로젝트를 하고 있는데 여러 기능을 개발하고 한 번에 머지를 한다면, 다른 팀원의 코드와 충돌날 가능성이 높아지고 이 충돌을 해결하는 데 많은 시간이 소요될 것이다.
이를 해결하고자, 지속적으로 & 작은 단위로 나누어 개발을 진행하고 메인 브랜치에 머지하자는 것이 CI, 지속적인 통합이다.
하지만 개발자가 직접 하루에 수십 번씩 빌드하고 테스트하는 것은 매우 번거로운 일이다!
==> 따라서 이를 자동화해주는 것이 필요하다.
Github Actions 등의 CI/CD 툴을 이용해 CI script를 만들어 빌드와 테스트를 자동화할 수 있다! - CD (Continuous Delivery / Deployment) : 지속적인 제공 / 배포를 의미한다.
CI 과정에서 에러가 발생하지 않아 빌드와 테스트가 성공적으로 완료된 후에는 배포를 할 수 있다.
이 때 배포를 개발자 혹은 배포 담당자가 직접 하느냐, 배포를 자동화시켜주느냐에 따라 Continuous Delivery와 Continuous Deployment로 나뉜다.
- Continuous Delivery (지속적인 제공) : 배포를 직접 수행
- Continuous Deployment (지속적인 배포) : 배포 자동화
아래 단계를 따라 Github Actions을 통해 쉽게 CI/CD 파이프라인을 구축할 수 있다.
1. Github 접속 >> 내 계정에서 secret 토큰 발급
개인 레포지토리와 organization 레포지토리를 안전하게 연동하기 위해 secret 토큰을 발급해야 한다.
1-1) 내 계정에서 settings > Developer settings > Personal access tokens > Generate new tokens 선택
1-2) secret 키 발급
- Note : 새로 생성될 토큰의 이름
- Expiration : 토큰 만료일 (나는 30일로 설정했다)
- Select scopes : repo 체크박스를 선택한다.
Generate token 버튼 클릭! 하면 토큰이 생성되는데, ghp로 시작하는 이 토큰은 한 번밖에 발급이 안 되니 안전한 곳에 저장해두도록 하자
2. 이제 이 키로 fork된 레포와 organization 레포를 연결해보자!
Organization 레포로 이동 >> Settings > Secrets and variables > Actions 으로 이동한다.
New repository secret 버튼을 클릭하여 secret을 생성한다.
- EMAIL => 본인의 이메일 주소
- AUTO_ACTIONS => 아까 생성한 ghp로 시작하는 토큰
3. Github Action을 위한 코드 작성
organization 레포에서 Actions 탭을 누르고 New workflow 버튼을 클릭한다.
그 다음 set up a workflow yourself 버튼을 클릭하면, 아래와 같이 .github/workflows 하위에 yml 파일이 하나 생성된다.
파일 내에 다음과 같이 코드를 작성한다.
- destination-github-username : 내 깃허브 계정 이름을 작성하면 된다.
(나의 깃허브 계정명은 YoungseoChoi23이기 때문에 나는 YoungseoChoi23으로 작성했다) - destination-repository-name : 내가 배포한 레포지토리 이름을 작성하면 된다.
(나는 개인 레포에 fork할 때 Frontend라는 이름을 그대로 사용했기 때문에 Frontend라고 작성했다)
name: Deploy
on:
push:
branches: [main]
jobs:
build:
runs-on: ubuntu-latest
container: pandoc/latex
steps:
- uses: actions/checkout@v2
- name: Install mustache (to update the date)
run: apk add ruby && gem install mustache
- name: creates output
run: sh ./build.sh
- name: Pushes to another repository
id: push_directory
uses: cpina/github-action-push-to-another-repository@main
env:
API_TOKEN_GITHUB: ${{ secrets.AUTO_ACTIONS }}
with:
source-directory: 'output'
destination-github-username: [나의 Github 계정 이름]
destination-repository-name: [배포한 나의 레포지토리 이름]
user-email: ${{ secrets.EMAIL }}
commit-message: ${{ github.event.commits[0].message }}
target-branch: main
- name: Test get variable exported by push-to-another-repository
run: echo $DESTINATION_CLONED_DIRECTORY
4. 배포 자동화가 잘 이뤄지는지 확인!
이렇게 코드를 작성한 다음,
직접 main에 PR을 보내고 머지를 해보자
Vercel로 배포한 주소에 들어갔을 때 PR 내용이 잘 반영되었다면 배포 자동화에 성공한 것이다!🎉
=> Actions 탭에서 모든 workflows를 볼 수 있고, 만약 PR이 반영이 안 된다면 이 workflows에서 에러 로그를 보고 어디가 문제인지 확인할 수 있다!
