- 0. Projcect Board & MileStones
- 1. Issue 생성 -> Commit & Push
- 2. Issue 기반의 브랜치 생성 -> Dev/ Commit & Push
- 3. Pull Request 요청
- 4. Code Review 완료
- 5. 메인 Branch 병합 및 릴리즈
> * Template를 활용한 일관된 형식의 이슈, 커밋, 풀리퀘스트
프로젝트 진행 중 발생할 수 있는 문제,기능 개선 등의 부분을 기록하고 추적하는 일종의 “할 일 목록”
> Github의 Issues는 개발에서 발견되는 버그, 기능, 개선 사항 등등을 추적하고 관리
> Issue = 기능 개발, 버그, 개선 사항 등등 모든 작업들을 의미
> 이슈를 생성시 제목, 내용, 라벨, 담당자, 마일스톤, 프로젝트 등의정보를 포함.
# 이러한 이슈들을 Github Project, Github Milestone을 이용하면 → 프로젝트 작업의 진행 상황을 파악하기 쉬움.
- Issue Template (GITHUB에서 재공하는 이슈 템플릿을 사용하거나, 별도의 이슈 템플릿을 작성하여 사용 가능.)
- Issue 기반 Branch 생성
- Project Board, Milestones
생성된 이슈는 오픈과 클로즈 별로 리스트 형태로 보여지는데 이슈들이 많아진경우 이슈를 찾기가 힘들어 지는 현상이 발생.
이런 경우 라벨을 사용하게되면 이슈 유형별로 라벨링을해서 찾고자하는 이슈를 손쉽게 확인 및 처리가 가능.
- 마일스톤 ( 사전적 의미는 "이정표" ) 관리
이슈와 이슈별로 라벨링을 하였지만. 현재 상태에서는 유사한 이슈들이 존재할것이고 이를 관리하기에는 어려움이 존재.
이를 위해 마일스톤을 사용하는것이 효율적인 프로젝트의 이슈 관리.
( 전체적인 작업에 진행 척도를 가시적으로 확인할 수 있다.)
프로제트에서 발생하는 모든 이슈별로 라벨링을하고 마일스톤을 사용하하지만 이와 함께 GITHUB의 PROJECTS을 사용하는것을 추천.
이기능은 칸반, 트렐로등과같이 유산한 기능을 제공하고있어 프로젝트의 이슈들의 시각하하여 프로젝트가 현재 진행중이고, 목표하고 있는것이 무엇인지 한 눈에 파악하기가 쉬움.
> 칸반, 트렐로, Github의 Projects등의 가장 큰 특징은 작업의 시각화라 할 수 있음.
프로젝트의 원본 저장소에 변경 사항을 제안하고, 그 변경 사항을 리뷰 및 토론하는 프로세스
PR 요청시 Github Actions 트리거를 발생시켜 코드 품질 관리 및 빌드/테스트 작업을 실행
- 리뷰어는 코드 품질 도구의 실행 결과를 참조하여 메인 브랜치에 Merge or Close.
- 코드 품질 관리 도구 종류 : CodeQL, SonarQube, Travis-CI, Jenkins, Github Actions Workflows etc.
- PR Template
- Github Action CI/CD
Approve: 코드에 대한 의문점이 없다면 승인 .
Comment: 간단한 피드백 제출
Request changes: 해당 코드에 문제가 있다고 판단되며 코드를 반드시 수정 요구
- 수동 or 자동(Github Action) 배포 가능한 소프트웨어를 제공하여 사용자가 다운로드하고 사용
공개 소프트웨어 연굴 개발 프로젝트에 관련된 사항을 문서화하는것은 프로젝트의 투명성, 지식공유, 협업의 원활함을 위해 필요
> 사용자용
- 릴리즈 노트, 시스템 요구 사항, 설치 가이드, 사용자 매뉴얼, 이전버전과 호환성을 유지하는 방법, 기능 리스트
> 개발자용
- 소스 코드로 작업하는 법, 빌드 방법, 아키텍처의 구성,
개발 프로세스 개요, 디버깅 방법, 테스트 자동화 방법,
패치를 제출하는 방법. API 활용 방법
> 프로젝트 활성화를 위한 기타 문서
- 라이선스, 제품 로드 맵, 개발 전략, 문서화 참여 방법, 도입 사례, 각종 백서
* Badge ( 프로젝트 레포지토리의 활성화를 위한 시각화 )
* READEME.md
* LICENSE.md
* CONTRIBUTING.md
* CODE_OF_CONDUCT.md
* 기여자 라이선스 협약(CLA)
* Discussions