현재 프로젝트를 진행하기 전 2번의 협업 시에 배포 및 CI/CD 작업을 다른 분이 해주셨다. 개인적으로 배포와 CI/CD 구축 작업을 경험해보고 싶어서 내가 해보겠다고 팀원들에게 이야기한 후 작업을 진행했다.
🔎 어떤 배포 서비스를 사용해야 할까??
Next.js로 구축한 웹 사이트는 어떤 호스팅 서비스를 이용해 배포해야 할지와 관련해 많은 고민을 했다. 구글에vercel vs netlify for next js,vercel vs netlify vs github pages와 같은 keyword로 검색 한 후 우리 웹 사이트에 적합한 배포 서비스를 찾기 위해 아래 글들을 읽어보았다.
🔎 vercel을 선택한 이유
고민을 하다 netlify와 vercel 중 하나를 선택하기로 했다. 무료 요금제인 상황에서 두 서비스의 큰 차이점이 없어 선택하기가 어려웠다.
- 두 서비스의 공통점
- Git 저장소와 연결하여 자동으로 빌드 및 배포
- 글로벌 CDN을 제공하여 전 세계 사용자에게 빠른 성능을 제공
- 프리티어(무료) 플랜이 있으며, 트래픽과 기능에 따라 추가 비용이 발생
- 그럼에도 vercel은 Next.js의 공식 호스팅 파트너로써 Next.js에 대한 강력한 지원(공식 지원 및 최적화)을 해주기 때문에 vercel을 선택하게되었다.
📌 Vercel로 Next.js 프로젝트 배포
- vercel 로그인 화면
- 이 글은
GitHub를 통해 배포를 진행을 할 것이므로 GitHub 버튼을 선택해 Login을 해준다.
Add GitHub Account버튼을 통해 개인 저장소 뿐만 아니라 다른 organization을 선택할 수 있다.- 배포하고자 하는 repository를 찾은 후 Import 버튼을 클릭
- Framework Preset이 next로 되어있지 않다면 설정(각자 선택한 라이브러리 및 프레임워크로 설정)해주고 Build Command toggle을 on 해준 다음 Deploy 버튼을 클릭하면 배포 => 배포가 이렇게 쉬울줄이야...
📌 Vercel의 협업 시 장점(자동 빌드, 자동 배포, 웹 사이트 미리보기)
- vercel은 등록한 repository에서 브랜치 생성 후 commit 또는 main 브랜치에 merge 작업을 할 때 자동으로 빌드테스트를 한다.
- 개발자가 따로 CI/CD(Continuous Integration/Continuous Delivery)를 구축하지 않아도 되어 개발에만 집중할 수 있다.
- 빌드 시 error가 발생하면 error 내용을 출력해주기 때문에 배포 전에 문제를 해결할 수 있다.
- PR을 open 하면 사진과 같은 메시지를 볼 수 있는데 Visit Preview를 클릭 해 다른 동료들이 진행한 작업을 배포 환경에서 확인할 수 있다!
- PR을 main으로 merge 하기 전에 빌드 테스트(2번째)를 통과하면 왼쪽에 check 아이콘이 보이고 아래와 같이 merge 버튼이 활성화 된다!
📌 CI(Continuous Integration) 구축
🔎 CI를 구축한 이유
- 위에서도 언급했듯이 vercel은 자동으로 CI/CD를 하기 때문에 CI 구축이 필요없다고 생각할 수 있다. 하지만 개인적으로 type이나 eslint error와 관련해 배포전에 check 해야겠다는 생각이 들었다. error가 있는 상황에서 프로그램이 정상적으로 동작한다면 개발자 입장에서는 정상적으로 동작하니 그대로 배포해야겠다는 생각을 할 수 있다.
- 지금은 실행에 문제가 없으나 그 오류가 쌓이고 쌓여서 실행에 직접적인 영향을 줄수도 있고 코드 품질 검사를 함으로써 장점이 많아
git action을 통해 CI를 구축하기로 했다.- TypeScript 및 ESLint를 통해 코드 품질 검사 장점 => 잠재적 error 제거, 코드 안정성 확보, 가독성 향상, 유지/보수 시 도움
- package.json 파일에 빨간 네모 부분의 코드를 추가한다.(각각 lint, type check 하는 명령어)
- repository의 Actions Tab에 들어간 후에 New Workflow 버튼을 클릭
- Choose a workflow에서
set up a workflow yourself클릭
name: 'Continuous Integration'
on:
pull_request:
types: [opened, synchronize, reopened]
jobs:
quality:
name: 'CI: Check quality'
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Install dependencies
run: yarn install --frozen-lockfile
- name: Check typescript
run: yarn type:check
- name: Check eslint
run: yarn lint- 적절한 파일명을 설정해준다(ex) CITest.yml)
- 소스코드 입력한 다음에 Commit Chagnes 클릭
- 소스 코드가 이해 안되면 Chat GPT에 복붙해서 구체적으로 해석해달라고 하면 친절하게 알려준다.
- 해당 소스코드는 필자 기준이므로 독자의 팀에서 검사 시점 및 종류를 의논해 프로젝트에 필요한 검사를 세팅하면 된다.
- 두번째 radio button 같은 경우 새로운 브랜치를 생성 후 해당 작업과 관련된 PR을 날리는 방법으로써 check한 후 Propose change 버튼을 클릭한다.
- 해당 작업의 목적 및 장점을 팀원들이 인지하도록 제목 및 내용을 작성한 후 PR Open
- PR Open 후 PR에 들어가보면 위의 사진의 빨간 네모 부분과 같이 코드 품질 검사를 진행하고 있다!(2번째 꺼는 기존에 설정해둔거라 무시하면된다.)
- type 및 lint check를 하고 error가 없으면 위에 사진과 같이 초록색 check 버튼이 보인다.
- 검사 도중 error가 발생하면 error가 발생한 시점으로부터 검사가 진행되지 않는다.
- 위에서 언급을 안했지만 vercel의 build test 뿐만 아니라 코드 품질 검사도 통과해야 merge button이 활성화 된다!
📌 코드 품질 검사가 통과 했을때만 main에 merge 되도록
- 코드 품질 검사를 통과하지 못한 상황에서 main으로 merge 하게 된다면 냉정히 말해서 검사를 할 필요가 없다.(물론 상황에따라 필요한 경우가 있을 수 있다.)
- 개인적으로 코드 품질 검사를 도입한 이유는 배포한 웹 사이트가 안정적으로 서비스되고 꾸준히 유지/보수 해야겠다는 생각이 있었기 때문에 꼭 필요했다!
- 그럼 검사가 통과했을 때만 main에 merge 하도록 하는 방법을 알아보자~
- Settings 탭에 Branches 메뉴를 클릭한 다음 Edit 버튼 클릭(Branch protection rules는 main 브랜치로 설정, 팀마다 다를 수 있는데 필자는 main으로 merge 할 때만 check 하면 되기 때문에 main 브랜치 설정)
- Protect matching braches의
Require status checks to pass before merging를 check 하면 하단에 검색 input이 뜬다. - CI 작업 name(위에 코드 참조)을 입력하면 자동으로 검색어 추천이 뜨고 선택하면 된다.
- 특정 작업을 선택하게 되면 위의 사진과 같이 보이고 검사가 통과했을 때만 main에 merge 하도록 할 수 있다.
📌 결론
배포 및 CI/CD 작업이 처음이라 쉽지 않을 것이라 예상했지만 vercel을 통해 쉽게 배포 할 수 있었다. CI 구축같은 경우는 많은 블로그 및 부트캠프 때 CI를 구축하신 분들이 어떻게 했는지 찾아보면서 해결할 수 있었다. 틀린 부분이나 수정할 부분 있으면 피드백 환영합니다!
📌 참조
https://velog.io/@mjooon98/Next.js-vercel%EC%97%90-%EB%B0%B0%ED%8F%AC%ED%95%98%EA%B8%B0
