브랜치 전략 변경

[whqtker]

기존 브랜치 전략

일반적인 흐름

1. develop 브랜치를 기준으로 feature 브랜치를 생성하여 작업을 진행.
2. 작업 후 feature->develop 로 PR 생성 및 머지.
3. 이후 CD 스크립트에 의해 stage 서버에 개발 내용이 반영.
4. 주기적으로 develop->release 로 PR 생성 및 머지.
5. 이후 release->master 로 PR 생성 및 머지.
6. master 브랜치를 기준으로 release를 발행. 이 시점에 CD 스크립트에 의해 prod 서버에 개발 내용이 반영.

핫픽스

1. master 브랜치에서 hotfix 브랜치를 생성.
2. 버그를 수정한 후 hotfix->master PR 생성 및 머지.
3. 이후 변경사항 동기화를 위해 hotfix->release, hotfix->develop으로 PR을 생성 및 머지.

문제점

1. release 브랜치의 존재 의미가 모호합니다. 단순히 develop 브랜치와 master 브랜치의 중간 다리 역할을 할 뿐, 그 이상의 의미는 없다고 판단했습니다.
2. 커밋(PR)이 아니라 기능 단위로 prod 서버로의 배포를 진행하기에, 급하게 필요한 기능만 prod에 반영하기 어렵습니다.
3. hotfix를 해야 하는 상황에서 롤백하기 어렵습니다. stage와 prod 서버에서 롤백용 이미지를 관리하고 있었으나, 배포 주기가 길었기 때문에 DB 스키마가 다를 확률이 높고, 롤백하더라도 스키마 불일치가 발생할 가능성이 높습니다.

변경된 브랜치 전략

일반적인 흐름

1. master 브랜치를 기준으로 feature 브랜치를 생성하여 작업을 진행.
2. 작업 후 feature -> develop 으로 PR 생성 및 머지.
3. 이후 CD 스크립트에 의해 stage 서버에 개발 내용이 반영.
4. 유동적으로 결정된 릴리즈 시점에 develop -> master 로 PR 생성 및 머지.
5. 이후 CD 스크립트에 의해 prod 서버에 개발 내용이 반영.
6. master 브랜치를 기준으로 릴리즈 및 이미지를 GHCR에 등록. 롤백 시 해당 이미지를 선택하여 배포.

핫픽스

1. prod 장애 발생 시 github action을 통해 GHCR의 이전 정상 이미지로 prod 서버를 즉시 롤백.
2. master 브랜치를 기준으로 hotfix 브랜치를 생성하여 버그 수정 작업 진행.
3. hotfix->master 로 PR 생성 및 머지.
4. CD 스크립트에 의해 prod 서버에 hotfix 내용이 반영.
5. 정상 동작 확인 후 develop 기준으로 sync/hotfix 브랜치를 생성, hotfix 커밋을 cherry-pick.
6. sync/hotfix->develop 으로 PR 생성 및 머지.
7. CD 스크립트에 의해 stage 서버에 hotfix 내용이 반영.
8. hotfix, sync 브랜치 삭제.

더 자유로운 develop 브랜치

• develop 브랜치의 PR 리뷰 제한을 없애고(그래도 가능한 리뷰는 받도록), 개인이 머지 가능하도록 변경할 예정입니다. 장애가 발생하면 revert를 하셔도 되고, 수정하는 PR을 올리고 머지하셔도 됩니다.

• PR을 생성할 때 진행중 / 최종 라벨을 달아서 올려주세요.

  • 진행중: 아직 완성되지 않은 작업을 stage에서 테스트하기 위해 임시로 머지하는 PR입니다. 리뷰어는 Request Changes 대신 Comment로만 피드백을 남겨주세요. 해당 피드백은 이후 최종 PR에서 반영하면 됩니다. 3일 이내 리뷰가 달리지 않으면 리뷰 없이 머지할 수 있습니다.

  • 최종: 작업이 완료된 PR입니다. 최소 1명의 리뷰를 받아야 합니다. 리뷰어는 Request Changes를 적극적으로 활용해주세요.

• develop -> master 배포 주기를 짧게 유지하려고 합니다. 이러한 상황에서 원치 않는, 불필요한, 미완성의 PR이 포함되어 배포될 수 있습니다. 이에 배포 일자를 미리 공유하고, 해당 날짜 이전까지 아래 중 하나를 선택하여 정리해주세요.

  • 작업을 완성하여 최종 PR로 마무리
  • 임시 작업물을 revert

• 다만 정말 불가피한 경우, 배포에 포함되어야 하는 PR만 cherry-pick하여 master로 머지를 하려고 합니다.

Q&A

• 위 내용에 대한 의견 및 질문 등등 아무거나 자유롭게 남겨주세요 !!

• master에서 feature 브랜치를 생성하기 위해 develop과 master의 커밋 히스토리를 일치시켜야 합니다. 좋은 방법이 있다면 제안해주세요.

  • master를 develop HEAD로 강제 이동시키기 (reset --hard)
  • cherry-pick
  • 기타

• github remote를 fork repo가 아니라 upstream에 직접적으로 연결하려고 합니다. 현재 방식은 개발 전 fork repo를 동기화 한 후, feature 브랜치를 생성해야 합니다. upstream에서 feature 브랜치를 생성하는 경우 브랜치가 많아질 수 있으나, PR 머지 후 해당 브랜치를 삭제하는 기능이 존재하므로, 브랜치가 많아지는 문제를 해결할 수 있다고 생각합니다.

• 변경된 브랜치 전략에서 각 PR에 대해 어떤 머지 전략을 취하는 것이 좋을까요 ? 이미지에서는 제 임의대로 작성했습니다.

[whqtker]

master CD가 실패하면 자동으로 이전 이미지로 롤백하는 기능 추가도 좋을 거 같습니다. 예전에 stage 서버의 헬스체크 확인이 제대로 되지 않아 개발자가 stage 서버가 죽은지도 모르는 일이 몇 번 있었는데, prod에서도 이러한 상황이 발생하면 치명적일 것이라고 생각합니다.

본 논의와 연관없지만, 서버 헬스체크 관련해서 로깅도 강화하면 좋을 거 같습니다. 서버 죽으면 디코로 알림 오게끔 ...

[Hexeong]

@whqtker 해당 부분에 대해서는 무중단 배포 리팩토링 시에 반영해서 디코 웹훅으로 정상적으로 CD가 완료되었는지 알림을 보내는 기능을 추가 반영하도록 하면 될 것 같은데 어떻게 생각하시나요?? 같은 이슈에 반영해서 진행해도 괜찮을까요??

[whqtker]

네 동의합니다 ~! 당장 브랜치 전략에 포함시킬 필요는 없다고 생각하고, 무중단 배포 작업 진행하실 때 포함시키면 될 것 같습니다 !

[whqtker]

master에서 feature 브랜치를 생성하기 위해 develop과 master의 커밋 히스토리를 일치시켜야 합니다. 좋은 방법이 있다면 제안해주세요.

master를 develop HEAD로 강제 이동시키기 (reset --hard)
cherry-pick
기타

저는 master를 develop HEAD로 강제 이동시키기 (reset --hard) 방법이 나을 것 같습니다. 현재 master 브랜치의 머지 커밋을 굳이 남기지 않아도 된다고 생각합니다. 체리픽하면 해당 커밋이 남아있게 되고, 체리픽해야 하는 커밋 또한 상당할 것 같습니다.

[Hexeong]

저도 체리픽으로 커밋 하나하나를 관리하는 건 관리 소요가 클 것이라고 생각되네요.. 성혁님 의견에 동의합니다!

[whqtker]

github remote를 fork repo가 아니라 upstream에 직접적으로 연결하려고 합니다. 현재 방식은 개발 전 fork repo를 동기화 한 후, feature 브랜치를 생성해야 합니다. upstream에서 feature 브랜치를 생성하는 경우 브랜치가 많아질 수 있으나, PR 머지 후 해당 브랜치를 삭제하는 기능이 존재하므로, 브랜치가 많아지는 문제를 해결할 수 있다고 생각합니다.

fork repo(기존 방식)을 사용하면 매번 기능 구현 시 repo sync 해야 하는 불편함이 생기고, 위 방식을 사용하면 머지 후 브랜치를 삭제해야 한다는 불편함이 있습니다. 제 개인적인 의견은 전자의 불편함이 후자보다 더 크다고 생각합니다.

[whqtker]

변경된 브랜치 전략에서 각 PR에 대해 어떤 머지 전략을 취하는 것이 좋을까요 ? 이미지에서는 제 임의대로 작성했습니다.

develop->master로의 PR 머지 방식은 fast forward 방식이 가장 좋을 것 같습니다(초기 브랜치 커밋 히스토리 동기화 시 reset --hard 방식을 채택한 경우)

두 브랜치의 커밋 히스토리가 아예 동일해지기 때문에, master에서 feature 파서 develop으로 PR 보내는 상황에서 커밋 히스토리가 꼬이는 상황이 발생하지 않을 것이라고 생각합니다.

다만 master 커밋 히스토리를 보고 릴리즈 경계를 파악하는 데는 어려움이 있겠지만(머지 커밋이 없으니까), 이러한 상황이 필요한 상황은 없을 거라고 생각합니다.

[Hexeong]

저도 성혁님 의견에 동의합니다. 찾아봤는데 github action 스크립트로 master 브랜치에 병합될 때 actions/create-release 같은 액션을 연동하면, 병합과 동시에 GitHub Release를 자동으로 생성할 수 있다고 알고 있어서 해당 방법을 사용하면 어느정도 버저닝에 대한 커밋 경계 파악이 가능하지 않을까 싶습니다! 릴리즈 생성시 반영된 커밋 제목들을 문서화해두면 좋을 것 같네요!

[whqtker]

오 그러면 너무 좋네요 ! master에서 롤백용 이미지들을 관리하기로 했으니, 그 이력으로 확인할 수도 있겠네요 ..!

[whqtker]

PR을 생성할 때 진행중 / 최종 라벨을 달아서 올려주세요.

진행중: 아직 완성되지 않은 작업을 stage에서 테스트하기 위해 임시로 머지하는 PR입니다. 리뷰어는 Request Changes 대신 Comment로만 피드백을 남겨주세요. 해당 피드백은 이후 최종 PR에서 반영하면 됩니다. 3일 이내 리뷰가 달리지 않으면 리뷰 없이 머지할 수 있습니다.

최종: 작업이 완료된 PR입니다. 최소 1명의 리뷰를 받아야 합니다. 리뷰어는 Request Changes를 적극적으로 활용해주세요.

develop → master 배포 주기를 짧게 유지하려고 합니다. 이러한 상황에서 원치 않는, 불필요한, 미완성의 PR이 포함되어 배포될 수 있습니다. 이에 배포 일자를 미리 공유하고, 해당 날짜 이전까지 아래 중 하나를 선택하여 정리해주세요.

• 작업을 완성하여 최종 PR로 마무리
• 임시 작업물을 revert

최종 라벨이 붙은 PR은 리뷰가 꼭 필요한 PR입니다. 깃허브/디코 알림 확인하셔서 리뷰 달아주세요 ..! 안 그럼 머지 못해요 ㅠㅠ

[whqtker]

추가로 매 PR 시 잊지 않고 진행 중, 최종 라벨도 붙여주셔야 합니다 !

[whqtker]

위 전략을 택한다면, 다음과 같은 작업 순서로 진행하는 것이 좋아 보입니다.

1. master 브랜치 동기화 (reset --hard)
2. develop 브랜치 리뷰어 수 0명으로 변경
3. 진행 중, 최종 PR 라벨 생성
4. release 브랜치 삭제
5. release 브랜치 정리(protection rule, 물리적 브랜치 삭제 등)
6. prod-cd.yml 수정 : prod 서버 배포, GHCR 이미지 생성 및 릴리즈 생성 트리거 만들기, release 브랜치 관련 트리거 제거)
7. 로컬 환경 동기화 : remote 변경 등

[whqtker]

새로운 브랜치 전략에서의 핫픽스 상황에 대해 추가 설명합니다.

hotfix 내용을 develop 브랜치에 반영하기 위해서는 반드시 핫픽스 내용을 체리픽하여 별도의 동기화 브랜치(sync)를 만든 후, 반영해야 합니다. 그래야 핫픽스 내용 반영해도 커밋 히스토리가 동일해지며, 이후 develop->master로의 원활한 ff merge이 가능해집니다.