문제
- MVP 개발하는 중이라 DB 구조 변경이 빈번하게 일어남.
백엔드 개발자가 2명이라 동시에 수정하는 경우도 많음.
⇒ 브랜치 머지할 때마다 → 장고 마이그레이션 파일 충돌 문제 발생.
⇒ 배포할 때마다 그러니까 → 서버가 계속 다운됨.
- 개발보다 마이그레이션 충돌 해결하는 데 시간을 더 많이 씀.
- 필요하다면 기존 마이그레이션 파일을 삭제하는 방식으로 해결하고 있었는데, 이러니까 기존 테이블을 싹 날리고 다시 생성해야 하는 상황 발생. (더미데이터 쌓았던 거 날리고.)
여태 시도했으나 실패한 방법들
[시도1] 로컬에서 해결 후 서버 배포
- 작업한 브랜치를 develop 브랜치에 PR 날려서 머지하기 전에 → develop 브랜치를 역으로 현재 브랜치에 pull해서, 로컬에서 마이그레이션 파일을 충돌한 후에 → develop 브랜치로 배포하자.
- 이유 : 서버가 다운되는 걸 막기 위해. (참고: develop 브랜치에 커밋되면 서버에 자동 배포되게 해놨다.)
- 문제 : 로컬에선 해결됐어도, 로컬 DB와 서버 DB의 스키마가 다르기 때문에 → 서버에서는 여전히 문제 발생.
[시도2] 로컬에서 개발 시 서버 DB 사용
- 로컬에서 개발할 때에도 로컬 DB 대신 서버 DB를 사용하자.
- 이유 : 방법1로는 충돌을 2번 해결해야 하니까, 로컬에서 해결하는 1번으로 줄여보자.
- 문제 : AWS RDS DB를 로컬에 연결하면 → 조회하는 데 너무 느렸다.
[시도3] 마이그레이션 파일을 gitignore에 추가
결론부터 말하자면 이러면 안 되고, 문제가 해결되지도 않았다. 꼭 커밋하자.
- 초기 개발 단계에선 DB 수정이 잦으므로 마이그레이션 파일 자체를 깃허브에 커밋하지 말고, 추후 DB 구조가 확정되면 그때부터 커밋하자. (gitignore에서 마이그레이션 폴더 삭제)
- 이유: 로컬, 서버에 각자 마이그레이션 파일 내역을 관리해도 models.py만 공유되면 최종적으로 DB 스키마는 같지 않나.
- 나중에 안 건데, 사실 DB가 다를 수 있다. 자세한 건 [여기]를 참고.
- 문제:
- gitignore에 마이그레이션 파일을 추가하면서 깃허브에서 마이그레이션 파일이 삭제됐다. 그래서 develop 브랜치에 작업을 커밋해서 서버에 새로 배포하면, 그 전에 서버에서 생성, 적용했던 마이그레이션 파일이 싹 없어진다. develop 브랜치에 마이그레이션 파일이 init.py 빼고 아무것도 없으니까, 배포하면 서버에도 그렇게 되는 것이다. (남아있을 줄 알았다...)
- 그래서 서버에서 makemigration 하면 매번 모든 내용을 0001 init으로 생성한다. 현재 DB가 어떻든간에. 그래서 migrate를 할 수가 없다.
- 내가 했을 땐 0001 init이 이미 적용된 상태라서 그런 건지, 명령어 실행에선 오류가 안 나지만 실제로 DB 스키마가 변경되지는 않았다.
- 내 생각엔, 이미 적용된 operator와 새로 수정해서 적용되어야 할 operator가 모두 0001에 있기 때문에, 어쨌든 문제가 생길 것이다.
해결 방법
[시도4] 이게 정석인 것 같다...
DJango 마이그레이션 내역 관리의 📌핵심📌
-
한 번에 한 사람만 수정하고, 다른 사람들한테는 배포 전까지 모델 건드리지 말라고 카톡으로 알려주기
- 이때 앱이 다르면 동시에 수정해도 괜찮다. 마이그레이션 파일이 앱마다 별도로 생성되니까 충돌이 발생하지 않는다.
-
꼭 모델 수정한 사람만 로컬 작업 브랜치에서 mikemigration하기
- 그 외 사람이나 서버에서는 makemigration 금지하고 migrate만 하기
-
충돌이 나더라도 크게 꼬이지 않도록, 수정할 때마다 자주자주 mikemigration하기
- 충돌이 나더라도 안전한 방법이 있으면 장고가 해결책 제안해준다. (merge하라든가.)
- 근데 많이 꼬이면 이런 거 없이 직접 수정해서 해결해야 된다고.
- 이때 다른 사람들과 함께 사용하는(깃허브에 올라간) 마이그레이션은 수정하거나 제거하지 않는 것이 원칙.
(+) 참고로 0001 같은 번호는 개발자 참조용이라 장고한테는 중요하지 않고, dependency만 중요하다고 한다.
