기존의 지혜로는 데이터베이스 마이그레이션이 VCS 내부에 유지되어야한다는 것입니다. 즉 데이터베이스가 통과 한 모든 변경 사항에 대한 기록이 있습니다.VCS 내에 데이터베이스 마이그레이션을 유지하는 것이 좋은 생각입니까?
하지만 ...
된 마이그레이션을 가진의 사용은 무엇입니까
? 나는 db의 옛 버전으로 되돌아가는 것을 보지 못했다. VCS에서 그들을 지키는 것이 더 쉬울 것이 아닌가요? 다른 모든 사람들과 동기화되어 유지 될 필요가없는 모든 컴퓨터에 마이그레이션 대기열을 만드시겠습니까?이전 마이그레이션을 유지하는 것이 낭비되는 경우 마이그레이션을 이해하지 못할 수도 있습니다. 마이그레이션을 통해 변경 사항을 롤백 할 수 있습니다. 당신은 그것을하는 것을 상상할 수는 없지만 필요할 수 있습니다. 전체 마이그레이션 기록을 통해 공동 작업 팀은 시작할 때의 버전과 상관없이 동기화 상태를 유지할 수 있습니다.
휴지통과 다시 시작은 남반구에서 할 수있는 최악의 경우 중 하나입니다. 모든 개발자에게 south_migrationhistory 테이블을 지우고 기존의 모든 마이그레이션을 삭제하고 새로운 init 마이그레이션을 생성하도록 명시 적으로 지시하지 않는 한 다른 개발자를 완전히 망쳤습니다.
요컨대. VCS에서 마이그레이션을 그대로 두십시오. 어디서나 프로젝트에 들어오는 모든 사람들이 자신의 db를 현재 버전으로 신속하게 마이그레이션 할 수 있도록하기 위해 소속 된 곳입니다. 그 (것)들을 청소하지 말라, 그들은 아무것도 아프지 않으며 당신은 이렇게함으로써 다른 협력자를위한 혼전을 창조한다.
이전 마이그레이션을 유지하는 데 거의 사용되지 않는다고 생각합니다. 아무리해도 해롭지 않더라도 내 프로젝트에서 사용되지 않는 코드가 마음에 들지 않습니다.
south와 같은 마이그레이션 시스템을 사용하면 개발 중에 많은 도움이되지만 통합 기능/변경 사항에 대해서는 이전 스키마 마이그레이션이 필요하지 않을 수도 있습니다 (그리고 여전히 Python 코드에서 모델 변경 사항을 사용할 수있는 경우 VCS).
가끔씩 하나의 초기 마이그레이션에서 모든 마이그레이션을 휴지통으로 다시 만들고 다시 시작하여 새로운 마이그레이션을 수집합니다.
VCS 외부로 마이그레이션을 유지하는 것은 문제가 발생하지 않을 경우 개발을 느리게 할 수 있으므로 VCS 외부로 마이그레이션하는 것이 좋습니다.
편집 : 정리 프로세스에는 팀이이 재구성을 인식하고 마이그레이션 기록 테이블을 지우는 것이 포함되므로 모든 개발자/사용자에게 쉽게 도달 할 수 없을 때 팀에서이를 제안하지 않습니다.
소규모 팀 또는 단일 프로그래머 팀에서 일하는 것은 어떻습니까? 마이그레이션 이력도 똑같이 중요하다고 생각하십니까? – Goro
네, 장래에 공동 작업자가있을 수 있고 좋은 습관이기 때문에 ... 그리고 다시는 어떤 것도 다치게하지 않으므로 왜 그들을 날려 버릴까요? 그리고 문제가 발생하면 배포를 위해 데이터베이스를 롤백합니다. – John
VCS를 사용하며 소규모 팀의 경우 VCS가 필요하지 않습니다. 정기적으로 GIT/SVN 저장소를 내보내고 다시 만드십니까? – John