들어가기 전
cypress 코드에 대한 설명은 하지 않습니다.
vercel, cypress, github actions의 설명보단 CICD flow에 집중합니다.
우당탕탕 구현한 사례입니다.
그래도 해당 과정이 나름 즐거워 글을 적어봤습니다.
상황
- 운영중인 서비스의 새 기능 개발
- 짧은 QA 후 배포
- 새 기능이 서비스 메인 플로우에 영향을 미쳐 예상치 못한 오류 발생
- hot fix 후 재 배포
문제점
- 사내 QA 엔지니어가 없는 상황에서 핵심 플로우를 QA 기간 내에 매번 수행하기에 피로감과 휴먼 에러란 예외 케이스가 존재
- hot fix로 인해 다음 스프린트 일정이 영향을 받아 기한엄수를 위해 야근하는 상황 발생
- 배포 주기가 일정하지 않아 배포 전 기도 🙏🏻 해야하는 상황 발생
해결방법
QA 엔지니어를 채용 전까지 핵심 플로우를 e2e 테스트(cypress)로 자동화하여 특정 상황마다 검증하기로 결정
* 특정 상황 - PR 요청, vercel 배포완료, git push 등등의 상황
코드 작성 전 상상해본 e2e 테스트 방법
첫 번째
- 작업내용 PR 요청
- PR 요청시 github actions 동작
- e2e 테스트 진행 (cypress)
- e2e 테스트 성공시 vercel 배포 스크립트 실행
- 해당 PR merge 가능 여부 판단. (vercel 배포 실패 or e2e 테스트 실패시 merge 불가)
두 번째
- push시 vercel deploy 자동 배포 trigger
- staging 브랜치 push시 github actions trigger
- 배포 완료 시점을 기다렸다가 github actions e2e 테스트 진행
- e2e 테스트 성공 실패 여부를 slack으로 전송
두 번째 방법으로 선택한 이유
꼼꼼한 사전 조사 없이 인생은 실전이라는 마인드로 약간의 사전 조사 후 바로 코드 작성이란 비효율적인 방법을 선택.
github actions 스크립트 하나만으로 모든 게 다 해피엔딩이 될 수 있을거라 생각하여 첫 번째 방법으로 시도.
(vercel 자동 배포를 수동 배포로 변경하는 설정 과정은 생략)
첫 번째 방법으로 구현한 github actions flow
- cypress job과 vecel deploy job 으로 나누어 cypress job 성공 후 vercel job 실행
- vercel 배포가 완료되면 특정 PR을 merge가능하도록 구성
문제점
기나긴 github actions 소요시간
github actions이 트리거되고 cypress job 실행 후
어?..
cypress job 성공 후 vercel job 실행
아..?
github actions 소요시간 9분30초
일단 파이프라인을 완성해서 뿌듯하긴 한데 아무리 그래도 9분 30초는…
두 번째 방법으로 선회 (개발시간 증가)
두 번째 방법으로 구현한 github actions flow
현 개발 환경은 위와 같이 구성되어 있고 staging에 push될 때 github actions 수행
여기서 관건은 “vercel 배포가 success된 시점을 어떻게 알 수 있을까” 였다.
github actions엔 배포 상황을 trigger 할 수 있도록 on: deployment_status란 event를 제공해준다.
github actions - deployment status
vercel 배포 상황에 따라 github actions를 수행할지 말지를 판단할 수 있다.
해당 방법으로 github actions 스크립트를 작성 후 feature branch → develop 으로 push해보니
배포 완료된 시점에 정확히 github actions이 실행되는 것을 확인할 수 있었다.
이제 다 왔다고 생각하던 찰나
“staging에 push될 때만 github actions을 수행해야하는데?”
란 물음으로 다시 구글 검색이 시작되었다.
다양한 시행 착오를 거쳐 나온 결론은
github actions에선 vercel에 대한 배포 환경 정보로 Production, Preview 인지만 구분하여 전달해주고 있었다.
하지만 사내에선 Preview 환경을 develop, test, staging 으로 구성해둔 상태라 staging을 구분할 방법이 없어 다른 트릭들을 다시 검색하였다.
위 2가지 방법뿐만 아니라 다양한 방법들을 수행해봤지만 원하는 대로 동작하지 않았다.
쉬운 선택
고민 끝에 아래와 같은 코드가 탄생했다.
name: specific flow
on:
push:
branches:
- staging
jobs:
cypress-run:
runs-on: ubuntu-latest
steps:
// ... 다른 step...
- name: Waiting for Vercel preview
uses: patrickedqvist/wait-for-vercel-preview@v1.3.1
// wait-for-vercel-preview 설정...
- name: Cypress run
//... cypress test에 필요한 정보...
slack-notify-failure:
needs: cypress-run
if: failure()
runs-on: ubuntu-latest
steps:
// rtCamp/action-slack-notify@v2 설정..
slack-notify-success:
needs: cypress-run
if: ${{ needs.cypress-run.result == 'success' }}
runs-on: ubuntu-latest
steps:
// rtCamp/action-slack-notify@v2 설정...코드 설명
specific flow란 이름의 github actions은 staging branch에 push될 때 동작한다.
name: specific flow
on:
push:
branches:
- staging
wait-for-vercel-preview 란 플러그인을 사용하여 preview 배포 여부를 판단 후 다음 step을 진행한다.
cypress-run:
runs-on: ubuntu-latest
steps:
// ... 다른 step...
- name: Waiting for Vercel preview
uses: patrickedqvist/wait-for-vercel-preview@v1.3.1
// wait-for-vercel-preview 설정...
- name: Cypress run
//... cypress test에 필요한 정보...
테스트 성공 실패 여부를 slack으로 전송한다. (rtCamp/action-slack-notify@v2 사용.)
slack-notify-failure:
needs: cypress-run
if: failure() // 실패할 경우 실행되는 job
runs-on: ubuntu-latest
steps:
// rtCamp/action-slack-notify@v2 설정..
slack-notify-success:
needs: cypress-run
if: ${{ needs.cypress-run.result == 'success' }} // 성공할 경우 실행되는 job
runs-on: ubuntu-latest
steps:
// rtCamp/action-slack-notify@v2 설정...두 번째 방법 소요 시간
vercel 배포는 역시 빠르다.
github action e2e 소요시간 2분 32초
총 4분가량 소요
성공적이라고 봐도 될까?
정리
- 밀도 있는 사전 조사를 통해 방향성을 명확히 정해야 시간 낭비를 하지 않는다.
개발의 시행착오는 경험이란 이름으로 체득되지만 돈받고 일하는 근로자라는걸 잊어선 안된다.
- 첫 번째 방법으로 진행했을 때 소요되던 9분이라는 시간이 두 번째 방법을 적용 후 약 4분으로 줄일 수 있었다.
- 뭐 어떻게든 적용은 했으니까 최적화는 다음 과제로 남겨두고..
- 좋은 방법을 알고 계시다면 연락부탁드립니다.