공통
•
기획자가 프로젝트를 기획한다.
◦
스토리 보드를 만든다. (기획서)
•
화면설계
•
기능을 정의한다.
◦
가능한지 못하는지 알아야된다.
백엔드
•
코드 컨벤션, 아키텍처 정의, 사용 기술을 선정
◦
mvc패턴
◦
사용할 기술을 선정
•
화면설계서와 기획서를 보면서 테이블을 설계
◦
애자일의 핵심은 피드백이다.
•
백엔드 개발자는 모르는 기능에 대한 레퍼런스 코드를 만들어야 된다.
◦
팀원들과 공유할 수 있도록 블로깅한다.
•
프론트엔 개발자와 기획자, 고객과 지속적인 커뮤니케이션 필요
•
구현된 프로젝트를 테스트 한다.
◦
여러가지 테스트 방법이 있다.
◦
시연영상에서는 잘 되는 기능만 테스트 할 것이다.
레포지토리 생성
•
yml세팅
•
필요한 테이블 세팅
•
패키지안에 파일이 없으면 깃허브에 안올라 간다.
◦
뭐라도 만들어서 폴더가 올라갈 수 있게 해야된다.
◦
temp파일이라도 만들어서 나중에 지울수 있게 하는게 났다.
◦
Controller, Repository,DTO 만들어서 준다.
◦
build_gradle, yml 세팅, 패키지 다 만들기!
▪
entity, req, resp, respository, controller
▪
헤더 푸터 설정
▪
매핑 연결 (주소에는 하이픈, mustache 카멜 표기법)
▪
팀장이 엔티티를 만든다.
•
팀장
◦
프로젝트 세팅
•
팀원
◦
회원가입
◦
로그인
◦
게시글목록 - 보
◦
게시글목록 - 페이징
머지 권한은 팀장이 가질 수 있게
또는 푸시할때 팀장의 동의를 구해야 할 수 있
팀원 할일
팀장 주소복사
git clone 팀장주소
SQL
복사
•
그리고 openFolder로 폴더 열기
브랜치 보호
•
dev 브랜치는 리뷰를 톹ㅇ해 승인해야 merge가능하게 세
require a pull request before merging
•
merge전에 pull request를 하도록 요구한다.
•
PR (Pull Request)
Require approvals
•
팀원이 푸시를 하면 바로 푸시가 안되고, 최소 1명의 승인이 필요하게 하는 설정
팀원들은 checkout 하면서 브랜치(topic)를 만들어 본다.
1. 회원가입.txt (topic-1)
2. 로그인.txt (topic-2)
3. 게시글 목록.txt (topic-3)
4. 게시글 목록.txt (topic-4)
git checkout -b 팀원 브랜치명
SQL
복사
3번 팀원, 게시글목록.txt 하고 ‘보기’ 저장
4번 팀원, 게시글목록.txt 하고 ‘페이징’ 저장
PR리퀘스트 후 머지가 완료되고 master를 체크아웃하고 형상을 맞추기 위해서 다시 master 브랜치를 다운받고 다시 브랜치를 다시 새로 만들어서 한다.
팀 협업 순서
팀장 레파지토리 오픈 팀원 클론
git clone 팀장주소
SQL
복사
팀원 브랜치 만들기
팀원들이 기능구현 하기위해서 브랜치를 각자 하나씩 판다.
git checkout -b 팀원브랜치이름 (T1,T2,T3)
SQL
복사
팀원 기능 구현후 Push 하기
팀원들이 기능을 구현후 Push 하면 각 브랜치는 클라우드에 등록이 된다.
git push origin master
SQL
복사
팀원 merge 요청
T1 브랜치를 만들었던 팀원이 Merge 요청을 한다.
팀장이 Pull Request 메뉴에 들어가 해당 Merge요청을 확인하고 코드를 검사한다.
코드 검사가 완료가 되면 Merge승인을 하고, 해당 T1브랜치가 Main Branch로 Merge가된다.
Merge가 완료될때!
팀원은 merge가 완료가 되면 본인의 MainBranch로 이동해야된다.
git checkout 메인브랜치 이름
SQL
복사
MainBranch 이동후 팀장Branch 동기화!!
자신의 메인 브랜치로 이동 후 팀장의 브랜치로 업데이트한다.
git pull origin master
SQL
복사
동기화가 완료가 된후에 새로운 브랜치를 만들어서 기능구현을 하면된다.
