내일배움캠프 TIL 62일차 - 파이널 프로젝트 EcoCanvas S.A (2/2)

https://sogummi.tistory.com/151

내일배움캠프 TIL 61일차 - EcoCanvas S.A (1/2)

=> 장바구니 부분은 삭제

 

API 명세

 

ERD

 

Team Convention(Ground Rule)

1. 매일 오전 스몰 토킹으로 분위기를 환기합니다.
2. 고정 회의는 매일 오후 7시
3. 회의 이외의 긴급 사항 또는 공유할 사항 또는 질문 사항이 있을 경우 슬랙에 회의 요청 가능합니다.
   • 가능하면 적극적으로 공유
   • 모여서 고민하되, 내가 더 급해! 하는 사람은 어떠한 이슈가 있는지 확인만 한 후 복귀
   • 튜터님께 질문하러 가기 전에 최대한 팀 내에서 먼저 고민하기
4. merge 는 모두가 마이크 켜고 모였을 때에만 가능합니다.
5. PR 시에는 코드 리뷰가 진행됩니다. (코드 리뷰 시 코드에 대한 서로의 의견 기록 남기기)
6. 주말 참석은 자율입니다.
7. 식사 시간은 따로 정하지 않습니다.(식사 시 팀원들에게 알려주고 자리 비우기)
8. 에러 노트 작성하기

Git Convention

• Git flow
  1. main branch - release branch - <기능> branch
  2. main
     • 브랜치 전략에 대한 고민
       1. 현재 채택중인 Git Flow를 사용한다. (채택)
          • Git Flow는 독립적인 개발 환경을 지녀 다른 사람의 개발 결과에 영향을 받지 않는다.
          • 칸반 보드의 티켓과 연동이 되어 기능의 오류를 추적하기 쉽다.
          • Branch의 업데이트에 맞춰 배포 및 테스트를 하기 용이하다.
          • Main Branch의 코드가 깔끔한 상태로 유지된다.
          • 단점으로는 많은 Branch로 인한 규칙이 복잡해지며 많은 동기화 작업을 필요로 한다.
       2. GitHub Flow를 사용한다.
          • GitHub Flow는 Main 과 Feature 로 이루어 지는 심플한 전략이다.
          • Main 브랜치의 모든 코드는 배포가 가능해야 함으로 머지 시 엄격한 검증이 필요하다.
          • 매우 빈번한 PR이 발생 한다.
          • Git Flow와 달리 Feature 브랜치를 Remote 환경에서 관리하는 것이 좋다.
          • MR 이 완료된 브랜치는 제거한다.
          • Main = 배포
          • 이는 소규모 팀 & 웹 어플리케이션에 매우 적합한 브랜치 전략이다.
          • 단점으로는 Develop 브랜치의 부재로 버그에 대해서 취약하며, 코드 리뷰나 인프라에 대해서 이해도를 필요로 한다는 점이 있다.
     • 이슈 기반 작업
       • 이슈에 대한 Branch를 생성한다.
       • 작업자는 여러 이슈 중 한 가지를 선택하고 해당 이슈에 대한 작업 Branch를 생성한다.
       • 생성시 작업의 명확한 구분을 위해 feature-#이슈번호 와 같은 방식으로 정한다.
       • Pull Request 시에 Conversation의 컨벤션은 하단의 양식과 같이 한다.
         • 해당 작업 내용 1
         • 해당 작업 내용 2
       • #Issue Numver
  3. release → release (Head)

 

Commit Message Convention

--- 제목(title) - 50자 이내로 ---
 <타입(type)> <제목(title)>
 예시(ex) : Docs : README.md 수정
 --- 본문(content) - 72자마다 줄바꾸기  ---
 예시(ex) :
 - Workflow
 1. 커밋 메시지에 대한 문서 제작 추가.
 2. commit message docs add.
 --- 꼬리말(footer) ---
 <타입(type)> <이슈 번호(issue number)>
 예시(ex) : Fix 
 --- COMMIT END ---
 <타입> 리스트
   Feat    : 기능추가
   Update  : 기능 보완 (업그레이드), 내용추가
   (Hot)Fix: 버그 수정, (긴급)수정
   Test    : 테스트 (테스트 코드 추가, 수정, 삭제: 비즈니스 로직에 변경 없음)
   Chore   : 기타 변경사항 (빌드 스크립트, 이름, 폴더명, 변수명 등 수정 
							& Pull 받기 전 임시 커밋 
							& 문서 관련
							& 리팩토링
							& 파일 삭제하는 작업만 수행한 경우)

# 작성예시
Feat : Campaign View 작성

커밋내용 ~~~~~~~

Feat #이슈번호

⇒ 깃 커밋 템플릿 설정해놓기 정리할때 커밋메세지 템플릿 으로 수정하기.

git config --global commit.template <.gitmessage.txt 경로>

 

Docstring Convention

class SampleView(APIView):
'''
작성자 : 아무개
내용 : 함수나 클래스에 대한 설명
최초 작성일 :
업데이트 일자 :
'''
	def Sample(request):
					.
					.

 

배포 전략

jenkins, docker, aws 사용

1. Jenkins를 활용하여 CI/CD 개발환경을 구축한다.
2. 서버는 CI/CD를 위한 서버와 실제 서비스를 배포할 서버 2개를 운영한다.
3. CI/CD 서버에는 jenkins가 Docker를 통해 컨테이너로 올라간다.
4. 도커 이미지는 jenkins:lts 를 사용한다.
5. jenkins와 github의 연동 시 보안을 위해 ssh key를 통하여 인증을 처리한다.
6. Push를 탐지할 브랜치는 main 하나로 한다.
7. 빌드의 성공여부는 Slack과 연동하여 팀 워크스페이스로 결과를 전달한다.
8. 빌드가 정상적으로 성공 햇을 시 Docker Hub로 버전을 업로드 하게 한다.
9. Docker Hub로 버전까지 업로드가 잘된다면 이때 서비스 서버에서 Docker Hub의 latest 버전으로 환경을 구축한다.

 

 

공휴일에도 풀출석 풀야근하는 우리조너무 만족 아자자자ㅏ!!