vercel로 프로젝트 배포하기
프로젝트를 진행했던 깃허브 레포지토리는 organization 레포지토리였다.
초기에 배포가 쉽고 간단한 vercel을 사용해 배포하기로하고, 프로젝트를 진행했는데 organization레포지토리는 유료제(정확히는 정해진 기간만 무료)인걸 나중에 알았다.
문제해결 -> 다른 문제발생
그래서 개인 레포지토리로 fork한 후, 최종 프로덕션 브랜치로 사용했던 master브랜치를 vercel에 연결하여 개인레포지토리 인 척(?)하여 배포에 성공했다.
그런데 프로젝트를 진행하면서, 자잘한 기능수정과 버그 수정 등이 생겨서 fork된 레포지토리를 매번 fetch and merge하여 싱크를 맞추기가 귀찮아졌다.
그래서 git actions를 활용하여 자동화 싱크 기능을 추가하였다.
깃 액션 사용하기
ref: https://stackoverflow.com/questions/23793062/can-forks-be-synced-automatically-in-github
fork해온 개인 레포지토리의 액션 탭으로 들어가서 새로운 액션을 만들었다.
코드는 스택오버플로우를 참고했다.
# org레포지토리에서 fork해온 현 레포지토리를 최신상태로 fetch and merge하는 스크립트입니다.
name: Sync and merge upstream repository
on:
workflow_dispatch:
schedule:
- cron: "0 8 * * *" #Runs at 8:00 UTC(5:00 in Korea) every day.
jobs:
merge:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- name: Merge upstream
run: |
git config --global user.name 'Hong-been'
git config --global user.email 'redbean-2@naver.com'
# "git checkout master" is unnecessary, already here by default
git pull --unshallow # this option is very important, you would get
# complains about unrelated histories without it.
# (but actions/checkout@v2 can also be instructed
# to fetch all git depth right from the start)
git remote add upstream https://github.com/Tinkerbell-Green/need-compliments.git
git fetch upstream
git checkout master
git merge -Xtheirs upstream/master
git push origin master
# etc- cron에서 얼마의 시간주기로 or 매번 언제 실행할건지 정할 수 있다.
- fork해오는 master브랜치를 덮어쓰기로 머지하도록 함.
성공~! 내일 아침에도 잘 되었는지 확인해봐야지.
여담
현재 프로젝트 진행해서 개선할 점
지금 프로젝트 방식은
- 기능을 나누어 개발자들이 구현하고
각자 구현한 브랜치--merge-->develop브랜치
- 배포가능한 단위가 되었다고 판단할 때
develop브랜치 --merge-->master브랜치
- vercel에 연결된 개인 레포지토리를 통해 배포하기 위해
master브랜치 --fork--> 개인레포master브랜치 --> vercel로 자동배포
위와 같다.
배포자동화 등의 키워드를 찾아보다가 무중단 배포, CI/CD 등이 자주 나오는걸 보았다.
포스팅한 글은 단순히 3번에 해당하는 fork한 레포를 자동 최신화 + vercel을 통해 자동 배포하는 부분이다. (vercel자동배포도 vercel에서 알아서 해줌)
테스트 코드의 부재, 불편함
-
일단 테스트 코드가 없어서 각 기능을 머지할 때, develop브런치에 끼치는 영향도를 알 수 없었고 각자 구현한 정확한 기능을 확인할 방법이 없었다. (머지할 때 사람이 코멘트로 설명을 남기는 수동작업 뿐)
그러다보니 코드를 여러번 읽어보고 머지해도 에러가 안날거라는 확신도 부족했고, 합치고보니 develop브런치가 예상과 다르게 동작한 경험도 있다. -
서로 부족한 점을 보완하기 위해 머지할 때마다, 코드리뷰를 진행했지만 역시 테스트 코드가 없으니 구현사항을 정확히 정의하여 공유하기 힘들었고 그에따라 리뷰할 때 드는 시간도 오래걸렸다. 중복된 의사소통도 많아짐.
테스트 코드의 필요성을 매우 느끼게되었고, 기능마다? 테스트 코드를 추가한다면 이 코드를 자동으로 실행시키고 통과되었을 때 개발브런치에 머지시키는 등을 자동화할 수 있는 CI/CD 프로세스가 필요하게 될것임을 예상할 수 있었다.
자꾸 되게 멋지고 유용한 기능을 구현 하는 데에 욕심이 난다. 하지만 다음 프로젝트를 진행한다면, 멋진 기능을 구현하기보다 구현한 기능의 신뢰성을 높일 수 있는 테스트 코드와 이 과정을 위한 CI/CD를 경험해보고싶다.
P.S.) 역시 선배 개발자들이 만들어 놓은 문화(개발 프로세스)는 다 필요에 의해 나온것임을.....
