surfers-root README.md

해당 레포지토리는 COLDSURF에서 관리하는 소프트웨어 자산들이 뭉쳐있습니다. yarn workspace를 사용해서 각각의 apps, packages를 관리 중 입니다. 아래에 읽어보면 좋을 자료들을 첨부합니다.

1. apps 깃 브랜치 전략

모노레포에서 여러 앱을 배포하면서 특히 React Native 앱을 배포할 때의 깃 브랜치 전략은, 기존의 main / develop / feature 구조를 유지하되 앱별 특화된 브랜치 관리를 도입하는 방식으로 개선할 수 있습니다. 이를 통해 병렬적으로 앱을 관리하고 배포 워크플로를 단순화할 수 있습니다. 아래는 제안하는 전략입니다.

---

1. 브랜치 구조

현재 main / develop / feature 구조를 다음과 같이 확장합니다:

공통 브랜치

• main: 모든 앱의 안정적인 프로덕션 배포용 브랜치.
• develop: 각 앱의 개발 통합 브랜치.
• feature/{앱이름}/{기능명}: 특정 앱에서 개발 중인 새 기능 브랜치.

앱별 브랜치

앱마다 독립적인 배포와 관리를 위해 앱별 브랜치를 운영합니다:

• release/{앱이름}: 특정 앱의 릴리즈 준비 브랜치.
  • 예: release/react-native, release/nextjs-web, release/node-server.
• hotfix/{앱이름}/{이슈명}: 특정 앱의 긴급 패치 브랜치.
  • 예: hotfix/react-native/login-crash.

---

2. 워크플로 설계

(1) 개발 단계

• 모든 새 기능은 feature/{앱이름}/{기능명} 브랜치에서 작업.
• 작업이 완료되면, 해당 브랜치를 develop 브랜치로 병합하여 통합 테스트를 수행.

(2) 릴리즈 준비

• 릴리즈가 필요한 경우, release/{앱이름} 브랜치를 생성.
  • 예: release/react-native.
• 해당 앱에서만 테스트 및 QA를 진행하며, 문제가 없다면 main 브랜치로 병합.

(3) 배포 및 태깅

• main 브랜치로 병합 후:
  • 앱별로 고유한 버전 태그를 추가.
    • 예: React Native 앱 배포 시 v1.2.3-react-native.
  • 배포 스크립트를 통해 앱을 스토어(앱스토어, 구글플레이) 또는 프로덕션 서버에 배포.

(4) 핫픽스 관리

• 앱에서 긴급한 수정 사항이 발생하면 hotfix/{앱이름}/{이슈명} 브랜치를 생성.
• 수정 후, **main**과 **develop**에 병합.

---

3. 병렬 관리 이점

1. 앱별 독립성 확보:
   • 한 앱의 릴리즈나 핫픽스 작업이 다른 앱의 배포 일정에 영향을 주지 않음.
2. 모노레포의 통합 테스트 유지:
   • 모든 앱의 개발은 develop에서 통합 테스트를 통해 검증.
3. 이슈와 기능의 명확한 구분:
   • 브랜치 이름에 앱 이름을 포함하여, 어떤 앱에 영향을 미치는지 명확히 알 수 있음.
4. 릴리즈 주기 최적화:
   • 릴리즈 브랜치를 통해 각각의 앱 배포 스케줄을 유연하게 조정.

---

4. CI/CD 통합

브랜치 기반 자동화

• release/{앱이름} 브랜치에 커밋 → 해당 앱만 빌드 및 배포.
• feature/{앱이름} 브랜치 PR → 앱별 테스트 실행.
• main 브랜치 병합 → 모든 앱의 안정 버전 빌드.

React Native 배포 자동화

1. release/react-native 브랜치 → 앱스토어/구글플레이에 자동 배포.
2. CodePush를 사용해 Over-the-Air 업데이트를 설정해 신속한 핫픽스 배포 지원.

---

5. 예시

새 기능 추가:

1. React Native 앱에서 새 기능 개발:
   • feature/react-native/new-login.
2. PR로 검토 후 develop 병합.
3. QA 완료 후 release/react-native 생성 → 테스트 및 QA 진행.
4. 승인 시 main으로 병합 및 배포.

긴급 수정:

1. React Native 앱 크래시 수정:
   • hotfix/react-native/crash-fix.
2. QA 후 main 병합 및 develop 병합.

---

이 전략은 앱별 병렬 작업을 지원하면서도 모노레포의 통합 관리 장점을 유지하는 데 중점을 둡니다. 추가적으로 CI/CD 도구를 활용해 자동화를 강화하면 더욱 효율적으로 운영할 수 있습니다.

2. packages 깃 브랜치 전략

모노레포에서 apps와 함께 공유 라이브러리나 유틸리티를 포함하는 packages 워크스페이스를 관리할 경우, 공유 패키지와 개별 앱 간의 의존성 관리와 배포 워크플로가 중요해집니다. 이 상황에 맞춰 브랜치 전략을 확장하고, packages에 대한 버전 관리 및 의존성 업데이트 흐름을 고려한 전략을 아래와 같이 제안합니다.

---

1. 추가되는 packages 브랜치 전략

packages 디렉토리에 대해 별도의 브랜치를 분리하여 관리하는 대신, 기존의 공통 브랜치 구조 안에서 통합적으로 관리합니다. 그러나, packages는 자체적인 배포 주기와 안정성을 보장해야 하므로 다음과 같은 추가 규칙을 도입합니다:

브랜치 구조

공통 브랜치와의 차이점

• main: 안정적인 패키지 릴리스 버전을 포함.
• develop: 앱과 패키지가 함께 작업되는 통합 브랜치.
• feature/{패키지명}/{기능명}: 특정 패키지의 새 기능 브랜치.
  • 예: feature/utils/add-logging.
• hotfix/{패키지명}/{이슈명}: 긴급 패치 브랜치.
  • 예: hotfix/ui-library/button-color-fix.

앱별 브랜치와의 협력

앱과 패키지 간 의존성을 해결하기 위해 release/{앱이름} 브랜치에서 사용하는 패키지 버전을 명확히 고정하거나 레퍼런스를 정의합니다.

---

2. 워크플로 설계

packages와 apps 간 의존성 관리와 배포 흐름을 최적화하기 위해 다음 단계를 추가합니다.

---

(1) 패키지 개발

1. 새로운 기능 추가

   • 특정 패키지에서 새 기능을 작업할 경우 feature/{패키지명}/{기능명} 브랜치 생성.
   • 완료 후 develop으로 병합하여 통합 테스트.

2. 통합 테스트

   • develop 브랜치에서, 앱들이 해당 패키지 변경사항과 함께 제대로 동작하는지 확인.
   • 이 과정에서 배포 전 패키지 버전을 snapshot 태그로 관리하여 변경된 패키지를 임시로 배포 가능.
     • 예: 1.2.3-snapshot.20240101.

---

(2) 릴리즈 준비

1. 릴리즈 분리

   • 패키지에서 변경 사항이 안정화되면, 해당 브랜치(예: release/utils)를 생성하여 테스트를 진행.
   • 이 브랜치는 앱이 해당 버전을 고정하여 사용할 수 있도록 패키지를 독립적으로 검증.
   • 검증이 완료되면 main에 병합.

2. 버전 태그 지정

   • 패키지를 독립적으로 배포하기 위해 npm이나 yarn workspaces를 통해 버전 태그를 부여:
     • 예: [email protected].

---

(3) 앱과의 의존성 관리

1. 의존성 업데이트

   • 앱(apps)의 release/{앱이름} 브랜치에서는, 패키지 변경 사항이 포함된 새로운 버전을 명시적으로 업데이트.
   • 예:

     {
       "dependencies": {
         "@workspace/utils": "1.2.3"
       }
     }

2. 병렬 개발 지원

   • 패키지와 앱의 변경사항이 동시에 필요할 경우:
     • feature 브랜치를 같은 이름으로 생성하여, 앱과 패키지의 병렬 개발을 지원.
     • 예: feature/login-improvement (앱과 패키지 모두 같은 이름으로 브랜치 생성).

---

(4) 패키지 핫픽스

1. 긴급 수정 브랜치
   • 패키지에서 발생한 버그를 수정하려면 hotfix/{패키지명}/{이슈명} 브랜치를 생성.
   • 수정 후:
     • main으로 병합하여 릴리즈.
     • 앱의 release 브랜치에서도 해당 버전으로 의존성을 업데이트.

---

3. CI/CD 통합

apps와 packages 간의 의존성을 관리하기 위해, CI/CD 시스템에서 의존성 추적과 자동화된 빌드/테스트를 설정합니다.

CI/CD 파이프라인

1. 패키지 변경사항 감지
   • 특정 packages 디렉토리에서 변경이 발생하면 해당 패키지를 빌드하고, 임시 버전(snapshot)으로 배포.
2. 앱에 자동 테스트
   • 패키지의 스냅샷 버전을 앱에 반영하여 통합 테스트 실행.
3. 릴리즈 및 배포
   • 패키지 릴리즈 후, 이를 의존하는 앱 릴리즈 브랜치에서 자동으로 의존성 업데이트 스크립트를 실행.

---

4. 전략의 장점

1. 효율적인 변경 관리:
   • packages와 apps의 브랜치가 독립적이면서도, 공통된 develop에서 통합 관리.
2. 앱별 배포 최적화:
   • 앱은 필요한 시점에만 packages 버전을 업데이트하여 릴리즈 주기를 조절.
3. 스냅샷 배포로 안정성 확보:
   • 변경된 패키지를 프로덕션 배포 전에 여러 앱에서 테스트 가능.
4. 병렬 개발 지원:
   • 동일한 브랜치 네이밍 전략으로, 앱과 패키지의 동시 작업을 쉽게 추적.

---

5. 예시 시나리오

(1) 새로운 기능 추가

1. 패키지 utils의 새 함수 추가 (feature/utils/new-function).
2. develop에 병합 후, 앱이 이를 통합 테스트.
3. QA 완료 → release/utils 브랜치에서 최종 테스트.
4. 배포 → [email protected].

(2) 앱 의존성 업데이트

1. 앱 react-native에서 [email protected] 사용:
   • release/react-native 브랜치에서 의존성 업데이트.
2. 통합 테스트 후, 앱 릴리즈.

(3) 긴급 패치

1. utils 패키지의 심각한 버그 발생 (hotfix/utils/crash-fix).
2. 수정 후, main에 병합 → [email protected] 배포.
3. 앱 release 브랜치에서 의존성 업데이트 → 앱 핫픽스 배포.

---

이 전략은 공유 패키지와 앱의 독립적 릴리즈 주기를 유지하면서, 모노레포 환경에서의 통합 개발과 배포를 효율적으로 관리할 수 있도록 설계되었습니다.