시작에 앞서,

웹사이트를 일단 배포하게되면, 가장 무서운 순간이 특정 코드를 업데이트 했을때 버그가 있는 코드를 미리 체크하지 않고 업데이트해서 사이트가 얼어버리는 순간이다. 나같은 경우는 백엔드를 heroku, 프론트를 netlify를 이용해서 배포를 했는데, 이번 포스팅에선 netlify를 통해 미리 테스팅 웹사이트에서 잘 작동하는지를 보고 이후에 production branch쪽으로 mergy해서 버그가 날 가능성을 낮추는 작업을 소개하려 한다.

Git branch 전략이란?

각각의 브랜치에 대해서 간략하게 알아보자.

feature

• feature 브랜치는 기능의 구현을 담당한다.
  브랜치명은 팀마다 컨벤션을 가지고 지을 수 있지만 feature/{구현기능명}과 같은 명칭을 준수하는 것이 일반적이다.
  예를 들어, feature/login은 login 기능을 구현하는 브랜치임을 알 수 있다.
  feature 브랜치는 develop 브랜치에서 생성되며, develop 브랜치로 머지된다.
  머지된 후에는 해당 브랜치가 삭제된다.
  develop
  develop 브랜치는 말 그대로 개발을 진행하는 브랜치로 중심적인 브랜치이다.
  하나의 feature 브랜치가 머지될 때마다 develop 브랜치에 해당 기능이 더해지며 살을 붙여간다.
  develop 브랜치는 배포할 수준의 기능을 갖추면 release 브랜치로 머지된다.

release

• release 브랜치는 개발된 내용을 배포하기 위해 준비하는 브랜치이다.
  브랜치명은 release-1과 같은 방식으로 첫번째 릴리즈, 두번째 릴리즈 등을 지정하는 것이 보편적이다.
  release 브랜치에서 충분한 테스트를 통해 버그를 검사하고 수정해 배포할 준비가 완전히 되었다고 판단되면 master로 머지해 배포한다.
  release 브랜치는 develop 브랜치에서 생성되며 버그 수정 내용을 develop 브랜치에도 반영하고, 최종적으로 master 브랜치에 머지한다.

hotfix

• hotfix 브랜치는 배포된 소스에서 버그가 발생하면 생성되는 브랜치이다.
  브랜치명은 hotfix-1로 지정된다. release 브랜치를 거쳐 한차례 버그 검사를 했지만 예상치 못하게 배포 후에 발견된 버그들에 대해서 수정한다. hotfix 브랜치는 master 브랜치에서 생성되며, 수정이 완료되면 develop 브랜치, release 브랜치와 master 브랜치에 수정 사항을 반영한다.

master

• master 브랜치는 최종적으로 배포되는 가장 중심의 브랜치이다.
  develop 브랜치에서는 개발이 진행되는 와중에도 이전 release 브랜치 내용이 master에 있어 배포되어 있다.

실제 적용하기

코딩을 하면서 느낀건 아무리 좋아보이는 기술이나 스택일지라도 항상 스테이지가 있다는 것이다. 내가 선택한 방법은 branch를 master, main, test 3개로 나눠서, 테스트 코드에선 새로 추가할 코드를 넣어서 main에 mergy하고, Main으로 production전에 배포상에 오류가 있나 없나를 확인한 후, 오류가 없을경우 main에서 master로 mergy하는 식의 프로세스를 만들었다.

Test Branch 만들고 코드 커밋하기

일단 기본적으로 자주 쓰는 git branch 명령어 정리

git branch 이름 // 이름이라는 브랜치 생성
git checkout 이름 // 이름이라는 브랜치로 이동
git branch -d 이름 // 이름이라는 브랜치 삭제
git mergy 이름 // 이름이라는 브랜치를 병합

브랜치에 test 브랜치 생성해보기

1. New branch 생성
   

2. new branch 버튼 클릭
   

3. create branch 버튼 클릭
   

4. Test 브랜치가 생성된거 확인
   

5. VS code로 돌아와서 git branch test 입력
   

6. git checkout test로 테스트 브랜치로 이동후에 test branch에 코드를 push
   

6. git-hub으로 돌아와서 확인을 하면 test 브랜치에에 있는 코드를 main 브랜치로 병합을 할 수 있다
   
   

배포용 브랜치와 테스트용 브랜치 따로 배포하기

워킹마스터의 프론트는 netlify를 통해 배포를 했다. 깃에 푸시를 할때마다 자동으로 배포가 되는데, master을 배포용, main을 테스트용으로 관리하기 위해 netlify로 main branch를 다시 배포했다.

마무리,

디자인 시안을 받아도 실제로 핸드폰으로 보거나 컴퓨터로 볼때 약간씩의 차이점들이 있었는데, 이렇게 배포용 코드와 테스트 코드를 따로 운영하다보니, 안정성도 기존보다 좋아지고 비개발 직군과의 소통을 할때도 한츰 편안해졌다.