프로젝트 진행 방법론
프로젝트 셋팅 완료 후 어떤식으로 프로젝트를 진행하는지에 대해 기술한 페이지이다.
팀원과 팀장의 프로젝트 셋팅이 끝났으면 각팀의 개발전략대로 프로젝트를 진행하면 된다. 단 정해진게 없으면 아래의 순서대로 작업을 진행해 보도록 하자.
1. 이슈 기반 개발(Issue-based-development)
프로젝트의 개발 과정을 "이슈"단위로 구분하여 진행하는 개발 방법론
프로젝트의 전체적인 기능을 잘게 쪼게어 별도의 이슈로 관리함으로써 빠르고 ,명확하게 개발을 진행할 수 있다. 즉, 큰 기능의 개발을 한번에 진행하는 것이 아닌 , 이슈단위 작은 개발을 빠르게 반복 하여 개발하는 방식
이슈기반 개발에서는 생성한 이슈번호와 작업내용을 합쳐서 브랜치를 생성한다
ex) 10번째 ISSUE 게시글에서 작업할 내용이 LOGIN이라면 ?
issue-10-login 으로 브랜치를 생성하여 작업한다.
이슈는새로운 기능, 개선 사항, 기술 제안, 일반 작업, 논의할 사항 등 프로젝트와 관련된 모든 정보를 의미한다.
2. GitHub Issue 작성방법
Settings - Set up Template 선택
기능 개발용 템플릿 선택(Feature request)
수정하기 선택
탬플릿 안의 마크다운에 다음 내용을 추가
Feature Request Template
Bug Report Template
수정 완료 후 커밋
이슈 생성
생성된 이슈 확인
이슈번호는 #3 번 이며 현재 상태는 Open(작업중)임.
이슈 종료는 하단 Close Issue를 추가하거나, 코멘트 및 커밋 메세지에 close, closes #3를 추가하면 이슈가 자동으로 닫힘.
3. 이슈 기반 개발 Work Flow
이슈 기반 개발은 GitHub Flow 브랜치 전략을 사용하여 브랜치를 관리한다.
GitHub Flow의 규칙에 따라 main브랜치는 항상 배포 가능한 상태로 준비하고, 새로운 작업은 feature branch에서 진행 후 , main에 병합한다.
작업이 완료된 branch는 원격과, 로컬 환경상에서 삭제처리 한다
상세 work flow
모든 팀원은 각자 할당 받은 요구사항에 대해 작업할 내용을 Issue로 등록한다
이슈가 생성되면 메인 브랜치로부터 해당 이슈번호를 딴 새로운 브랜치를 생성한다.
ex) 10번 이슈게시글에서 Login 기능을 추가한다면 -> issue-10-login으로 브랜치명 생성
개발자는 새로 만든 브랜치에서 코드를 작성하고 커밋 한다.
커밋 시에는 반드시 이슈번호를 추가하여 ex) #10 어떤 이슈에 대한 수정사항인지 표시한다.
작업 완료 후, 원격저장소로 push하고 메인브랜치로 병합요청(PR)을 보낸다.
PR을 보내기전 main브랜치를 feature브랜치와 병합해보고, 충돌이 발생한다면 해결하고 push한다.
pr 코멘트 작성시 어떤 이슈에 대한 코드수정인지를 반드시 기술한다.
이슈를 자동으로 완료(close)상태로 변경하기 위해 Closes #이슈번호를 PR내부에 코멘트로 추가한다.
팀원들은 PR요청이 있는 경우 코드를 리뷰하고, 개선사항이 있는지 확인하고 코멘트를 남긴다.
피드백이 있다면 추가 반영 후 다시 커밋하고, 문제가 없다면 MAIN브랜치로 merge한다.
merge후에는 원격 레파지토리의 작업용 branch를 삭제하고 , 로컬 레파지토리의 작업용 branch도 삭제한다.
원격 브랜치는 자동삭제 옵션 추가하여 관리하자.
작업 완료 후 , 작업결과를 협업도구(notion, discored 등)를 통해 팀원들에게 노티한다.
작업중이던 팀원은 main 브랜치의 내용을 pull을 받은 후 본인의 feature 에 통합(merge)후 작업을 이어서 진행한다.
Issue를 처리완료(Closed) 상태로 변경한 후 이후 진행할 작업에 대한 Issue를 새롭게 생성하고, Issue에 맞춰서 작업용 branch를 다시 생성한다.
이후 1~8번 과정을 반복하면 끝.
Last updated