Hi

  1. 애자일 스크럼 방식으로 진행됩니다.

  2. 반복주기가 최고 핵심 가치입니다.

  3. 조기 최적화 때문에 출시일이 밀리지 않도록 주의합니다.

    적어도 나중에 수습이 가능한 정도로 개발합니다.

워크 플로우

프로세스

  1. Milestones 생성 (에픽)
    1. 에픽은 작업을 거시적으로 그룹화하고 계획하는 방법입니다.
    2. 이 페이지에 에픽에 대한 추가 컨텍스트를 입력해도 되지만, 해당 템플릿은 관련 작업 내에 세부 정보를 입력하도록 구성되었습니다.
    3. 타겟데이트 작성
    4. 하위에 작업이 붙습니다.
    5. 문서 형태
      1. 문제 정의
      2. 성공 기준
      3. 사용자 스토리 (QA)
  2. Issues 생성 (task)
    1. 유형 구분을 잘해주세요 (기능 추가인지? 버그인지?)
    2. 우선순위를 구분해주세요 (마일스톤에서 이슈가 몇 번째 순서인지?)
  3. Project 등록 (스프린트 or project)
    1. 이슈를 한눈에 관리합니다. (어떤게 진행 중인지? 병목 현상 확인)
  4. Branch 생성
    1. 팀 매뉴얼에 맞게 브랜치를 생성합니다.
    2. 로컬 캐쉬 이슈를 막기 위해서 Prod 배포 마다 새로 clone 하도록 합니다.
    3. 만약 기존 브렌치가 존재하면 꼭 fetch 후 pull 하도록 합니다.
  5. 생산
    1. 컨벤션과 팀 매뉴얼에 맞게 작업합니다.
  6. PR (CI Unit Test)
    1. 필수적으로 필요하여 CI/CD가 연계되어 있습니다.

시나리오

사전에 해야하는 마일스톤과 이슈가 있어야 합니다.

  1. main branch를 origin으로 develop branch를 생성합니다.

    1. github에서 gitflow시 develop → main 과정에서 계속 충돌이 발생하여 main 으로 병합될 때마다 병합되는 branch (해당 context에서는 develop) 가 삭제되도록 되어있습니다.

      Untitled

    2. 그래서 새로 feature 작업할 때 develop branch를 생성해야하는 것입니다.

  2. develop branch를 origin으로 feature/{기능 단위} branch를 생성합니다.
  3. 해당 branch에서 작업을 진행합니다.
    1. 2명 이상 작업하는 경우 충돌 문제가 업도록 fetch & pull을 필수적으로 하도록 합니다.
  4. 작업이 마무리 되어 기능 출시를 위해서 PR을 작성합니다.
    1. PR target branch는 반드시 develop 를 선택해야합니다. 미 선택시 첫 PR이 Build 되지 않습니다.
    2. PR과 동시에 qa서버에 배포됩니다. 이때부터 리뷰어와 함께 테스트를 진행합니다.
    3. develop from feature/* 해당 내용을 참고해서 작성해주세요.
  5. 배포 승인자가 PR 내용대로 문제가 없다면 PR이 통과되어 develop 와 병합됩니다.
    1. 스쿼시 커밋 그리고 머지을 하도록 합니다.