내일배움캠프 37일차
[오늘 한일]
- 장고drf 팀프로젝트 시작
- 프로젝트 회의, S.A. 제출
- 프로젝트 생성, 초기설정
[오늘 배운점]
오늘 드디어 팀프로젝트가 시작됬다.
프로젝트에 대한 회의와 초기 설정을 하며 배운점이 많다.
<깃 협업 규칙, 커밋 메세지 컨벤션>
이번 프로젝트에서는 깃을 더 깔끔히 써보고 싶다.
그리고 브랜치 작명규칙을 끝까지 지켜보기로 함께 다짐했다.
깃 협업규칙으로 정한건 3가지이다.
-PR과 병합하는 방법.
-브랜치 작명규칙.
-커밋 메세지 작성규칙.
얘기를 나눠본 결과, pr과 병합은 간단한 방법을 사용하기로 했다.
(각자 fork에서 브랜치를 만들고 main레파지토리로 바로 pr하는 방법이다.)
브랜치 작명규칙은 이전 프로젝트에서 하던것보다 더 디테일하게 정했다.
feature/user/signup 이런식으로,
큰구분/앱이름/기능이름 이렇게 작성된다.
큰구분으로 feature, hotfix, minorfix등을 써서 브랜치의 목적을 구분할수 있어서 좋은 것 같다.
커밋 메세지 작성규칙에 대해 함께 고민해봤는데,
(동사+내용, 동사+파일명 등의 의견이 나왔다.)
고민하던중, 인터넷에서 적절한 컨벤션을 찾게 되었고 그걸로 지켜보기로 결정했다.
커밋 메세지 작성 컨벤션인데, 컨벤션보다 가이드 정도의 느낌인것 같다.
내용은 아래와 같다.
-feat : 새로운 기능을 추가하였을 때
-fix : 버그를 수정하였을 때
-docs : README 등 문서 내용을 변경하였을 때
-style : 들여쓰기, 세미콜론 등을 변경하였을 때
-refactor : 코드 리팩토링을 했을 때(기능의 변경은 없어야 한다.)
-test : test코드의 작성 및 수정이 이루어졌을 때
-chore : 외부 라이브러리 임포트 등의 작업을 완료했을 때
작성법은 위를 글머리로 시작하고, 뒤에 내용을 적는 식이다.
참고링크 (https://doublesprogramming.tistory.com/256)
<ERD 작성 사이트 대안>
노션에 피그마를 연결하듯이,
ERD를 연결해서 S.A.를 스마트하게 만들어 보고 싶었다.
하지만 ERD cloud는 이런 연결을 지원하지 않는다.
링크를 html태그로 제공하긴하는데 (그래서 티스토리 블로그에는 ERD를 삽입할수 있다.)
노션에서는 html태그를 적용할 방법이 없었다.
png파일로 '내보내기'를 해서 이미지 첨부를 할수 밖에 없었다.
그런데 팀원분께서 dbdiagram이라는 사이트를 시도해보셨고,
이 홈페이지는 노션에 연결이 된다.
한번 더 반복작성 하시지 않고,
erdcloud에서 sql문을 추출해 dbdiagram에 붙여넣어 만드셨다.
결론, erd cloud의 대안이 될수 있다.
erd cloud와 달리 노션에 연결이 된다.
sql문을 이용해 자동작성을 지원한다.
<dotenv 시크릿키 정식적인 보안>
프로젝트 폴더를 처음 만들고 초기세팅을 역시 해주었다.
그중 .env에 secret키를 따로 설정해주는 작업도 했다.
.env는 gitignore로 제외되니 공유가 되지 않아 secret키를 지킬수 있다.
(이렇게 하지 않을경우 github에서 경고 메일을 보내준다.)
그런데 새로 알게된 부분이 있다.
담당자가 .env를 설정하여 github에 올렸다면,
다른 팀원들은 이걸 클론받고 .env파일을 각자 생성해줘야한다.
나는 그동안 .env파일을 별도의 방법으로 팀원들이 전달받는게 방법이라고 생각했다.
그런데 오늘 팀원분께 배우게 됬는데,
각자가 로컬에서 secret키를 생성해서 .env를 직접 만들어 줄수 있다.
이 키는 내 작업환경과 내 key가 맞기만 하면 되기때문에,
꼭 같은 key를 공유하지 않아도 되는 것이다.
게다가 .env를 전달한다는 것은 secretkey를 전달한다는 것과 같은 의미가 되니,
보안적으로 맞지 않는 방법이다.
결론, .env는 각자 시크릿 키를 생성하여 작성해주는게 맞다.
보안에 알맞다.
<협업 노하우. 낮은 버전의 파이썬으로 venv 만드는 방법>
만약 팀원들끼리 설치되있는 파이썬 버전이 다르다면?
예상치 못한 문제가 일어날 가능성을 안은채 그냥 진행할수도 있겠다.
하지만 적절하지 않다.
파이썬 버전을 정하고 그걸로 맞춰서 개발하는게 이상적이다.
그래서 초기단계에서 이런걸 정하는거 같다.
우리팀은 파이썬 버전이 3.11, 3.8로 상이했다.
그래서 낮은 버전인 3.8로 정하기로 했다.
(낮은 버전으로 진행하는게 더 비교적 포괄적이기때문에 유리하다고 하셨다)
만약 컴퓨터에 3.11과 3.8이 깔려있는 상태에서,
3.8로 venv를 생성하는 방법은 아래 사진과 같다.
-해당 버전파이썬이 설치되있는 경로를 찾는다.
-python프로그램의 위치를 확인하고 그 경로를 복사한다.
-터미널에서 경로+python -m venv venv를 입력한다.
(cmd에서 입력한다. bash에서는 복사해온 디렉토리가 알맞지 않다.)
<vscode 설정 파일 만들기>
코드컨벤션도 정했는데,
파이썬 포맷터로는 black formatter를 사용하기로 했다.
html 포맷터로는 prettier를 써보기로 했다.
오늘 처음 알게되었는데,
vscode설정은 크게 사용자에게 저장된 설정과 작업영역에 적용된 설정으로 나누어진다.
그래서 사용자의 설정과 상관없이 작업영역에 설정을 팀에 함께 적용할수있다.
작업영역 설정은 .vscode폴더에 settings.json파일로 저장된다.
작업영역에 별도 설정을 한다면 자동으로 만들어지므로 이 파일을 깃허브에 포함시켜 공유하면 된다.
거꾸로, settings.json을 통해 설정을 바꾸는게 가능하다.
(공유 받는 입장에서는 이렇게 적용될것이다.)
결론, vscode 설정파일을 이용해서 포맷터 설정을 팀에 적용할수 있었다.
포맷터를 이용해 커밋내역에 불필요한 부분을 없애겠다!
※물론 포맷터만 의존하면 안되고 눈으로 검토도 해야한다.
<더 알게 된점>
- 프로젝트 폴더, 앱폴더, 마이그레이션 폴더 아래 __init__.py는 꼭 깃에 포함되어야 하는 파일이다.
모듈로 불러오는데 사용된다.
- 개발환경관리는 poetry를 시도해볼지 고민되었으나, 우선 requirements.txt를 사용하기로 했다.
나중에 여력이 된다면 적용해보고 싶다.