[OpenRoadmaps] 1. 프로젝트 시작

Intro

드디어 마지막 학기다. 그동안 공부한 지식들로 졸업작품을 만들어야 한다.

사실 졸업작품 주제로 미리 생각해둔게 있었는데, 한 줄로 정리하면 다음과 같다.

자신만의 로드맵을 만들고, 다른 사람이 만든 로드맵을 따라 공부할 수 있는 웹사이트

 

프로젝트 이름은 OpenTutorials.org 에서 따왔고, OpenRoadmaps.xxx 도메인으로 배포도 해볼 예정이다.

 

백엔드는 미리 공부해둔게 있어서 큰 걱정이 없지만, 프론트엔드 개발에 시간이 꽤나 들어갈 것 같다.

---

프로젝트 기능

회원가입 / 로그인

• Email / Password 로그인
• OAuth2 (Google / Github) 로그인

로드맵

• 로드맵 보기
  • 로드맵 항목과 연결선으로 구성된 트리 구조 (최대 1개의 부모 항목을 가질 수 있음)
  • 로그인된 사용자는 로드맵 항목 완료 표시 가능
  • 로드맵 항목은 중요도에 따라 추천 / 대안 / 비추천 / 없음으로 설정 가능
  • 로드맵 항목 클릭 시 참고 URL과, 해당 항목을 주제로 작성된 포스트 목록 표시
  • 좋아요 및 신고 기능
• 로드맵을 직접 만들 수 있는 편집기
  
  • 로드맵 항목 추가 / 삭제
  • 드래그를 통한 로드맵 항목 위치 변경
  • 더블클릭으로 항목 이름 변경
  • 연결선 지정, 연결 가능한 지점에 힌트 표시
  • 중요도 설정
  • 참고 URL 목록 설정
  • 대표 이미지 설정
• 다른 사람이 만든 로드맵 검색, 정렬
  
  • 이름으로 검색
  • 최신순 / 좋아요순 정렬

블로그

• 글 편집기
• 로드맵 항목 태그
• 대표이미지 설정

프로필

• 사용자 사진 / 이름 표시 및 변경
• 작성한 로드맵, 글 목록 표시

---

프로젝트 관리

Github 브랜치 전략

한 repo에 Frontend와 Backend 코드를 같이 관리해야 하기 때문에, 브랜치 관리 방법이 중요하다.

[작업 단위] / [be / fe] / [작업 내용] 과 같이 브랜치 명을 관리할 예정이다. Ex) feat/be/roadmap-create, fix/fe/login-session

작업이 완료된 브랜치는 main 브랜치에 pull request를 보내고, merge 하기 전 테스트를 진행하도록 할 예정이다.

 

main 브랜치에 merge된 이후, deploy 브랜치에 merge 시키면 AWS에 자동으로 배포되도록 할 예정이다.

 

CI / CD

Frontend 관련 브랜치는 Frontend만 테스트하고, Backend 관련 브랜치는 Backend만 테스트를 진행해야 한다.

위에서 브랜치 전략을 */fe/**와 */be/**으로 정했으니, main에 pull request된 브랜치 명을 통해 테스트하면 될 것 같다.

---

기술 스택

이번 프로젝트를 구현하기 위해 사용할것으로 생각되는 기술들이다.