[vercel] 서브 도메인을 이용한 사전 배포 시스템 구축
date
Feb 22, 2023
slug
vercel-서브-도메인을-이용한-사전-배포-시스템-구축
category
Dev
status
Public
tags
SEO
Next.js
Front-end
CI/CD
keywords
summary
상용에 배포하기 전, 사전 배포를 통해 내부에서만 사용해야 할 일이 생겼다
type
Post
Last updated
Feb 23, 2023 09:05 AM
Created time
Feb 23, 2023 12:53 AM
1-2월 기간동안 새로운 기능을 구현하였고, QA까지 완료가 된 상태였다.
다른 플랫폼의 QA가 안끝나서 상용 배포를 대기하던 중, 오늘 스크럼시간에 나온 새로운 요구사항이 생겼다.
요구내용
B2B대상 플랫폼만 먼저 배포해서, 로그인한 대상이 우리 회사 계정이면 그 기능을 쓸 수 있게 해주세요.
그렇게 하려면..
- 로그인 한 유저가 우리 계정일 때
- 새로 배포한 기능을 사용할 수 있도록 한다.
- 로그인 한 유저가 우리 계정이 아닐 때
- 새로 배포한 기능이 있는지 모르게 해야하나요?
- 새로 배포한 기능이 있지만 못쓰게 해야하나요?
- 새로 배포한 기능이……
몇 주 뒤에는 쓰이지도 않을 불필요한 로직이 생기고 말 것이 불가피했다.
이렇게 해보면 어떨까?
그래서 이를 코드로서 분기하는 것이 아닌, 서브 도메인을 하나 새로 파서 네트워크 페이즈에서 관리하고자 했다.
우선 해당 플랫폼은 Vercel을 사용하여 CI/CD가 관리되고 있었다.
그래서 아래와 같은 방법으로 요구사항을 처리해보고자 했다.
- vercel의 프로젝트 세팅에서 domains에 서브 도메인을 하나 구축한다.
- 해당 도메인에는 preview라는 브랜치를 바라보고 CI/CD되도록 한다.
- 배포 레벨은 preview로 설정하여 외부에 크롤링 되지 않도록 한다.
이렇게 진행하면 매우 깔끔하게 요구사항을 정리할 수 있을 것 같았다. 하지만..
만약 외부 사용자가 url로 직접 접근하면?
설령 외부 크롤러봇들에게 크롤링되지 않아서 검색엔진에 노출되지 않더라도 url을 혹여나 직접 타이핑해서 들어온다면?
실서버 API를 바라보게 할 사전배포 프로젝트이기 때문에, 예측할 수 없는 사이드 이펙트가 발생할 수 있다.
이 마저 방지하기 위해, vercel의 authentication을 사용해보기로 했다.
vercel의 authentication이 뭔데?
vercel의 가이드 문서에는 vercel을 통한 배포를 보호하기 위한 방법으로 vercel authentication을 제공한다고 설명하고 있다.
password protection으로 암호를 요구하는 보호 옵션도 제공하지만, 유료인 것 같아서 패스했다.
어느정도 괜찮은 가격대면 구독을 요청하고자 했으나 경영진분들이 흠? 할만한 월 150$의 가격이기 때문에..
vercel authentication으로 보호 옵션을 활성화 해보고자 한다.
세팅해보자!
설정하는 방법은 가이드에 따르면 매우 간단했다.
- 보호하고자 하는 프로젝트를 선택하기
- 해당 프로젝트의 설정을 조정하기 (Settings > Deployment Protection)
- 프리뷰 배포 보호 여부를 토글하기 (Protect Preview Deployments)
끝!
확인해보자
시크릿 탭에서 확인해본 결과, 의도대로 매우 잘 동작해주었다
vercel의 세션이 있다면 해당 페이지를 보여주고, 아닐 경우 vercel의 로그인 화면으로 리다이렉트된다.
+ 이슈가 생겼다.. 테스트서버도 프리뷰였던것
위 적용한 프로젝트는 기존에 실서버와 테스트서버로 하나의 vercel project에서 관리되고 있었다.
- 실서버 (production)
- 테스트서버 (preview)
- + 사전배포서버 (preview)
테스트서버가 preview로 배포되었던 것을 망각한 채 배포했더니, 테스트서버에서도 권한을 확인하고자 했다.
이 이슈를 해결하기 위해 또 다시 작업을 해야 했다.
어떤 방법이 있을까?
막연히 생각해 본 것은 테스트서버 배포환경을 production이나 development로 바꿀 수 있지 않을까? 였다.
그래서 여러가지 찾아봤는데.. 찾아낸 방법은 아래와 같다..!
- 하나의 레포를 대상으로 여러개의 vercel 프로젝트를 생성한다. 즉 실서버용 프로젝트, 테스트용 프로젝트를 나누는 것.
- 현재 그대로 세팅을 하고, 사내 공유용 계정을 등록해서 필요할 때 마다 인증을 통해 사용하는 것.
- 추가된 도메인을 보호하지 않는것..
위 내용을 토대로 1번이 가장 이상적이라고 판단되어 제안했고, OK받아서 진행해보고자 한다.
기존 하나의 프로젝트로 관리되던 것을 두 개로 쪼개기
결론
요즘 vercel이 next.js 13도 그렇고, 매우 많은 발전을 보이고 있는 것 같다.
이정도의 기능을 무료로 제공해주고 있다니.. 14가 나오기 전엔 유료화 되지 않을까? 걱정해본다 😟
예전엔 항상 무작정 요구사항을 충족시키고자 작업을 바로 시작했는데, 불필요한 리소스를 덜기 위해서는 이렇게 작업 전에 리서치를 해보는 습관을 들이는 것이 좋을 것 같다.
nexjt.js 짱짱맨
참고 문헌