Git Zone & Git Flow

Zone

- zone 마다 서버의 수가 다를 수 있다

1. Local: 실제 개발을 진행하며, 디버깅 및 로컬 테스트를 수행하는 로컬 환경

   - Local DB: 가벼운 테스트를 위해 개발자가 직접 적재  혹은 로컬 실행을 통해 적제되는 정보

 

2. Develop Zone: 마무리 된 개발에서 누락된 테스트 케이스는 없는지, 개발자에게 노출(배포)

   - Develop Zone DB: 테스트를 위해 개발자들이 직접 적재

   - 로컬보다 데이터량이 많다

   - 내가 짠 코드를 남이 테스트 해준다

 

3. Staging Zone: 운영존에 가장 가까운 환경, 최종 배포전 네트워크 및 인프라 환경에 대한 마지막 테스트

   - Staging Zone DB: 운영존과 가장 가까운 수준의 데이터량을 적재한다

   - 내가 짠 코드를 남이 테스트 해준다

 

4. Production Zone: 실제 유저가 사용하는 환경으로 개발 및 수정들에 신중해야하며, 제약이 심하다

   - Production Zone DB: 실제 유저가 사용하는 운영 DB

 

비교

- DB 데이터량: 

   - 1 (Local) : 10 (Develop) : 1000 (Staging) : 10000 (Production)

   - 이렇게 점진적으로 올려 데이터량 때문에 발생하는 예측하지 못한 오류가 생기는 것을 방지한다

   - Staging -> Production으로 갈때는 Sync & Sanitize가 필요하다

      - Sync: 데이터에서 몇 퍼센트만 가져와서 테스팅을 일단 해본다

      - Sanitize: 개인정보를 암호화한다

 

 

 

Git Flow (Git 브랜치 전략)

1. Main / Master: 배포 브랜치

• 버그가 없어야하며 완벽한 코드 형태이여야 한다

2. Develop: 테스트 브랜치

• 마지막 테스트를 진행하는 곳
• Feature branch는 매번 develop branche에 merge되어 테스트를 진행해야한다

3. Feature: 개발 브랜치

• Develop Branch를 기점으로 새 브랜치를 만들어 개발한다
• 로컬에서 개발을 완료한 경우, Develop Branch에 PR 요청을 하여 마지막 테스트를 준비한다

 

Project Owner: 프로젝트를 자식처럼 키운다

Project Manager: PO가 PM에게 일을 준다

   - 비지니스 관점에서 일을 나눈다

   - 타임라인을 정한다

TL: 기술적인 관점에서 타임라인을 정한다

   - PM과 싸워서 (진짜 싸우진않음...) 맞춘다

Manager: 티켓을 만든다

   - 티켓 = task: 작업의 단위 (feature로 나눈다)

   - 이후 개발자가 와서 티켓을 가져간다

 

Pull Request

Commit을 올릴때 타입과 설명을 해주면 좋다