장고 마이그레이션에 대한 개념이 아직 확립되지 않았던 입사 초창기에 범했던 실수.
1. 문제 상황
개발하던 도중 마이그레이션 파일이 약간 꼬이는 일이 생겨서 무서운 마음에 원격 실서버 브랜치에 있는 모든 마이그레이션 파일들을 복붙 하여 로컬로 가져왔었다. 그러나 실서버 코드를
pull 해오지는 않았다. 즉 실서버에 반영된 마이그레이션 파일은 가져왔지만 로컬의 models.py는 그대로인 것이다. 이 상태에서 실수로 makemigrations 명령을 수행했는데, 그 결과 최신 마이그레이션 파일에 의해 추가하려던 어떤 한 필드(A라고 하자)가 models.py에 정의되어 있지 않았기 때문에 필드 A를 역으로 지워버리는 마이그레이션 파일이 만들어진 것이다.상황은 여기서 더 심각해진다. 저 상태에서 내 로컬 코드를 테스트 서버 브랜치에 병합시킨 것이다. 그러니 테스트 서버에서는 내 로컬에서 새로 만들어진 마이그레이션 파일을 통해 테스트 서버가 아니라 실서버에 병합시킨 것이었으면 진짜 망했을 뻔했다. 불행 중 다행이랄까.
migrate 명령이 수행되었고, 그 결과 테스트 서버 DB에서는 필드 A가 존재하지 않는 스키마 정보가 적용되면서 필드 A 정보가 전부 날아가게 되었다. 이로 인해 테스트 서버는 먹통이 되어버렸다. 2. 해결
그러면 어떻게 이 상황을 해결했을까? 첫 번째 시도로, 실서버 코드를 로컬로
pull을 해온 뒤 다시 테스트 서버에 나의 로컬 코드를 병합시켜봤으나 문제는 해결되지 않았다. pull을 해온다고 해서 내가 잘못 만든 마이그레이션 파일이 사라지지는 않기 때문이다. 다음으로는, 로컬에서 잘못 만든 마이그레이션 파일을 삭제한 뒤 실서버의 DB를 로컬과 테스트 서버에 덤프를 씌웠다. 그 상태로 테스트 서버 브랜치에 다시 병합시켰더니 테스트 서버가 다시 정상 작동하였다.3. 결론
장고에서 개발할 때는 항상 다음 세 가지의 싱크를 맞추도록 주의해야겠다.
- 각 앱의
models.py에서 정의하는 내용
- 각 앱의
migrations폴더에 있는 마이그레이션 파일들의 내용
- 실제 DB에 반영되어 있는 스키마 정보
