01_SQS 의 배포 프로세스
개발자의 데일리 루틴 : 핫픽스가 있을 수 있으므로 출근하자마자 prod 와 fetch 작업 루틴화
hotfix 배포자는 해당 채널에 prod merge 완료 후 노티한다.
dev 배포 : 각자의 feature 에서 작업 후 수시로 dev 병합,
stg 배포 : FT 테스트 후 3주차 금요일 핸드오프 전
prod 배포 : 4주차 QA 기간 내 stg에서 인수테스트 후, 합격 시 최종 배포
stg 는 실제 릴리즈된 prod와 동일해야 하기 때문에 prod 와 버전 동일.
와 배포내역 관리는 배포시점에 진행
prod 배포 전 버전 업데이트
기능의 범위와 유형에 따라 major, minor, patch 결정
→ package.json 의 버전은 결정한 버전으로 변경한다.
빌드 & 배포
릴리즈 노트 작성
Advanced : 자동화 할 수 있는 파이프라인이 있으면 좋을것 같다
02_Merge 전략
소제목
fast-forward
merge commit 은 커밋로그와 머지 로그가 동시에 기록되지만 commit log 의 순서가 머지 순서와 다르기 때문에 히스토리 관리가 어려우므로 제외했다.
feat → develop 머지 : squash merge 권장
각자 작업한 여러개의 feat 브랜치를 dev 로 한 데 묶어서 dev 에는 기능 단위로 커밋이 추가되도록 한다.
이전에 작업한 커밋 이력은 사라지게 되므로 깔끔한 브랜치관리가 가능하다. 대신 롤백은 불가하다.
develop → stg → prod : rebase merge 권장
stg 의 상태는 준 prod 상태로 생각하며, 핸드오프까지 종료된모든 QA 가 이뤄지므로 커밋 이력이 필요할 수 있다. squash 는 커밋이력을 삭제시키므로 브랜치관리는 깔끔하게 관리될 수는 있어도
특정 기능에서 문제가 생겼을 때 롤백하기 어렵다.
하지만 rebase merge 는 merge commit 과 달리 merge 순서대로 로그가 기록되고 커밋로그와 섞이지 않아 커밋메세지만 상세히 적는다면 롤백이 보다 쉬워질 수 있다.
⚠️ 룰이 지켜지지 않을 경우, merge 할 때 conflict 가 나는 상황이 발생 할 수 있다.
왠만하면 하나의 merge 전략으로 통일하고 싶은데 어떤 방식이 보편적인 방식으로 적합한지 정해야 할듯 하다.
그동안의 경험으로 보아 충분히 테스트 했다고 판단하여 올릴 때 editor 에서 설정한 값까지 고려하지 못하여 터지는 문제들이 있었다. 이때 dev 는 squash 머지를 이용하고 있었기 때문에 롤백이 불가하여 push 하는데 시간이 걸렸었다. 이처럼 dev 브랜치 이더라도 생각보다 rollback 할 일이 종종 생기므로 rebase merge 가 적합하다고 생각한다.
다만 rebase merge 는 conflict 가 발생하여 rebase 를 해야 할 경우, git 명령어가 익숙하지 않으면 또 헤멜 수 있다.
그렇기 때문에 여러가지 테스트케이스를 설정하여 rebase merge 를 하더라도 바로 적용할 수 있도록 하려고 한다.
테스트케이스 1 전체 리베이스머지로 merge
- dev 를 기점으로 각자의 feature 브랜치 생성
- dev
테스트케이스 2 : 푸쉬하기 전, 특정 커밋으로 되돌리기
테스트케이스 3 : 푸쉬한 후, 특정 커밋으로 되돌리기
============
rebase 를 잘못 했을 때, rebase 되돌리기
git reflog
git reset --hard 0de2b0cdf70b4d27f9864ac7a4f2b90fd8c5e717
테스트케이스 1 : 2.0.0 버전에서 시작
dev → stg pull request
pull request 된 상태에서 version 태그 생성 한다.
이때 버전은 스프린트에서 새로운 기능이 추가되어 FT 가 종료된 후 올라가기 때문에 2.1.0 이 된다.
stg 에서 QA 에 올라왔을 경우
dev 에서 작업된것들 중 prod 올라가면 안되므로 stg 에서 브랜치를 파서 작업한다.
local stg 에서 새로 파지 말고
origin stg 를 가져오기 위해서
git remote -t origin/stg
git fetch origin stg
git tag : tag 로그 보기
git tag -d v2.1.0 : tag 로컬 삭제
!! 무조건 pr 로 날리기!!
결국에는 merge commit
03_배포 버저닝
소제목
Lerna vs Standard-Version
✅ Standard-Version
예시
v 2.1.1
major
next.js 13 → next.js 14 버전처럼 아예 이전에 사용했던 기능 자체가 바뀌어 버린 경우, 마이그레이션이 진행 된 경우에 바뀌며 거의 사용할일이 없다.
minor
새로운 기능이 추가가 되었으나 이전의 기능이 유지 될때 적용한다. 스프린트가 끝나고 마이너버전 업 해서 적용하면 된다.
스프린트 종료 후 stg 와 prod 의 버전이 동일해야 한다.
patches
hotifx 나 QA 처리로 인한 작업이 있으나 기능적인 변화는 없을 때 적용.
prod 에서 hotfix 를 바로 처리해야 하는 경우가 많기 때문에 stg 와 patch 버전은 동일하지 않아도 된다.
ex )
stg 1.1.10
prod 1.0.1
연관성 없음
만약 QA 때 수정사항이 생기면 반드시 stg 에서
만약 dev 로 가면 해당 스프린트에서 올라가지 말아야 할 사항까지 올라갈 수 있어 위험하다.
만약 dev 로 가면 해당 스프린트에서 올라가지 말아야 할 사항까지 올라갈 수 있으므로
브랜치를 따서 작업해야 함.
hotfix 올린 사람이 책임지고 stg , dev 적용