배경
상용 django 환경에서 버전 업데이트시 앱 마이그레이션 문제로 고충을 겪게 된다.
현재 팀에서 django 관련 프로젝트가 처음이라 그런지, 상용 프로젝트 버전업시 migration 파일을 전부 날리고 새롭게 구축하는 비효율적인 부분이 반복되고 있었다.
그에 따라 migration을 어떻게 하는 것이 적합한지 스터디하고 진행해보았다.
마이그레이션 파일은 절대 지우면 안된다.
기본적으로 기존 마이그레이션 파일은 절대 지우면 안된다.
코드 업데이트시마다 필요한 마이그레이션 파일들이 새롭게 생성되며, 해당 마이그레이션 파일을 통해 디비에 변경부분이 적용된다. (makemigrations, migrate)
만약 기존 마이그레이션 파일을 지운다면, 코드와 디비간의 업데이트 히스토리가 모두 삭제되어있기 때문에, Django가 똑똑하게 디비의 구조를 확인하고 알아서 추가해주면 좋겠지만 해당 부분은 아직 불가능한 부분이다.
만약 마이그레이션 파일들이 모두 삭제됐다면, 코드와 싱크를 맞추기 위해 DB를 직접 커스터마이징해주어야하며, 코드에서 생성된 마이그레이션 파일은 fake migrate를 하여 마치 수행된 것처럼 django를 속여야한다.
그 과정에서, DB를 직접 커스터마이징한 부분들은 결국 런타임 에러로 장애로 연결될 수 있는 여지가 다분하다.
코드 업데이트시 마이그레이션 방법
기본적으로, 마이그레이션시 안정성을 장담할 수 없다면 dumpdata 명령을 통해 장고의 마이그레이션 전 데이터를 백업하는 것이 좋다.
# python manage.py dumpdata > xxx.json
// 전체 덤프
# python manage.py dumpdata appname > xxx.json
// 특정앱만 덤프
# python manage.py dumpdata --exclude appname > xxx.json
// 특정앱만 빼고 덤프덤프된 데이터는 아래와 같이 django에 입력할 수 있다.
python manage.py loaddata xxx.json마이그레이션 파일 삭제시 대처방법
마이그레이션 파일을 실수로 삭제했다면, makemigrations으로 마이그레이션 파일을 새로 생성하고, 생성된 파일에 맞게 기존 DB를 수동으로 업데이트해준 후, 마이그레이션 히스토리의 해당 마이그레이션을 강제로 완료됐다고 변경해주어야한다.
그 과정에서 필요한 명령어들은 아래와 같다.
- 마이그레이션 히스토리 확인
python manage.py showmigrations- 특정 앱의 마이그레이션 히스토리 초기화
python manage.py migrate --fake appname zero- Fake migration
python manage.py migrate --fake-initial
python manage.py migrate appname --fake-initial
// 특정 앱만 페이크 마이그레이션- 주의: auth.permission, authtoken의 충돌이 발생하면 상황이 많이 복잡해진다. 해당 앱들에 대해서 충분히 인지하고 DB데이터를 덤프/로드하자
참고 페이지: https://wikidocs.net/9926#_4
