여러 코드 브랜치로 Django South를 사용하기위한 워크 플로우

Question

여러 코드 브랜치로 개발할 때 다른 Django 개발자가 South에서 데이터베이스 마이그레이션을 관리하는 방법에 대해 궁금합니다. 샘플 시나리오를 알려 드리겠습니다.

예를 들어 주 트렁크로 개발을 시작한다고 가정 해보십시오. 트렁크에서 지점 A를 만듭니다. 이 시점에서 app_1의 마지막 마이그레이션 버전은 0010입니다.

그런 다음 0011_add_name_column이라는 마이그레이션 파일을 만드는 트렁크에 app_1에 대한 마이그레이션을 만듭니다. 한편, 지점 A에서 다른 개발자는 지점 A에 동일한 app_1에 대한 다른 마이그레이션 파일을 만듭니다. 0011_increase_value_column_size.

브랜치 A는 결국 트렁크로 병합됩니다. 이 경우 지점 A에있는 app_1의 마지막 이전 버전은 0020이고 트렁크의 마지막 버전은 0018이며 모두 다른 마이그레이션입니다. 보시다시피, 마이그레이션 파일의 상태는 버전 0011 이후로 엉망입니다. 분기가 트렁크에서 분기되면서 병합시 충돌이 발생했습니다.

South's tutorial에 따르면이 경우를 처리하는 유일한 방법은 모든 충돌을 수동으로 해결하는 것입니다. 그러나 충돌의 양이 큰 경우에는 실제로 원하는 솔루션이 아닙니다. 대개 어떻게 이런 상황을 처리합니까, 아니면 처음에는 그것을 피하기 위해서입니까?

Answer 1

글쎄, 이에 대한 대답은 그리 간단하지 않습니다. 우리는 트렁크 < 이야기하는 경우, 대부분의 경우 를 - 아마

1. 하나의 마이그레이션에 지점 A로부터 새로운 마이그레이션을 "압축"것> 분기 워크 플로우를 (또는 :;

   TL DR 업데이트 최소 가능)

2. 모든 트렁크 변경/마이그레이션을 지점 A에 병합하십시오.
3. 브랜치 이름 바꾸기 A 등등으로 마이그레이션합니다.
4. 이제 트렁크에 병합하십시오. 서로 다른 가지를 병합에서 같은 접두어 여러 마이그레이션 (즉 0011)이있는 경우

더 상세하게 모든

첫째, 그것은 중요하지 않습니다, 는 한대로 수정하지 않습니다 같은 모델. 그런 다음 --merge 옵션을 사용하여 마이 그 레이션을 실행하면 순서가 다른 마이그레이션을 적용 할 수 있습니다.

그러나 동일한 앱에 대해 0011 -> 0018 및 0011 -> 0020의 두 가지 다른 '이전 경로'가있는 경우에도 동일한 모델을 터치하지 않아도별로 좋지 않습니다.

1. 그 가지가 매우 긴 시간 동안 분리되어 있고 2 스키마에 큰 차이가있다 : 나는 그것이 하나 가능성이 높습니다 생각합니다. 이 가능한 상황이 여기에 있습니다 :

   가

   • 그들은 같은 모델 (즉 그들은 "교차"하지 않음)에 접촉하지 않는 : 당신은 그냥 --merge와 순서가 적용 할 수 있습니다, 그러나 매우 가능성이 높습니다 영향을받는 모델은 2 개의 별도 앱에 더 잘 속해야합니다.

   • 그들은 (나는 그것이 귀하의 경우 아마 가정) 같은 모델을 만지지 할 : 나는 그것을 더 나은/분할 처리 작업을 조정하여 모두 이러한 상황을 방지하기 위해 최선의 것을, 여기 @chrisdpratt에 동의해야합니다. 이 경우에도 특히 스키마 마이그레이션 만있는 경우 특히 두 분기에서 명백하게 충돌하는 스키마 마이그레이션을 수행하지 않는 경우 (바보 같은 예제는 같은 모델의 동일한 모델에 2 개의 다른 필드를 추가하는 것입니다. 마이그레이션)을 사용하면 문제없이 --merge을 사용하여 마이그레이션 (또는 대부분은 대부분)을 순서대로 적용 할 수 있습니다. 대부분의 경우 동일한 모델에 영향을 미치더라도 스키마 마이그레이션 순서는 중요하지 않지만 수동으로 확인해야합니다. 문제가 발생하면 번호 매기기를 변경해야합니다. 자동으로 주변에 번호가 표시되지 않습니다.

2. 당신은 모든 작은 스키마 변경을위한 새로운 스키마 마이그레이션을 생성 :이 개발 중에이 아무 문제가 없다,하지만 기능은 마이그레이션이 하나의 마이그레이션에 "압축"해야한다 (병합에 대한 준비가) 완료되면 (또는 일부 논리적 그룹과 함께 많은 변경 사항이 있거나 데이터 마이그레이션이있는 경우 최소한 마이그레이션은 필요하지 않음). 단지

   • 는 myapp와 0010
   • 가 마이그레이션에게 0011-0018
   • ./manage.py schemamigration의 MyApp를 삭제 --fake 마이그레이션 ./manage.py 할 이미 최신의 마이그레이션은 간단한다 dev에 환경에 schema_changes_for_new_feature_x --auto
   • ./manage.평 0011 --fake --delete-유령 마이그레이션

MyApp를 마이그레이션 또 다른 것은 다른 마이그레이션 두 지점 사이에 병합 후, 자주와 (A mergefix 스키마 마이그레이션을 작성해야한다는 점이다 "고정 된"모델에 결합 된 상태를 기록하는 것입니다 (그렇지 않으면 South은 탁월한 스키마 변경이 있다고 생각합니다)

Answer 2

가능한 경우 내 대답에서 마이그레이션을 커밋하지 않았습니다. 잃어 버리면 마이그레이션을 다시 생성 할 수 있으므로 아무도 필요 없지만 내 지점을 실행해야한다고 가정하고 끝까지 마이그레이션하지 마십시오.

간단히 말해서 가장 좋은 방법은 병합 충돌로 처리하는 것입니다. 트렁크에 다시 병합 할 때 마이그레이션 폴더를 확인하고 마이그레이션 번호를 더 높은 번호로 변경하여 각 번호 매기기 충돌을 독립적으로 해결하십시오.

부여되었지만 어느 방법도 이상적이지는 않지만이 전면에는 많은 옵션이 없습니다. South's own advice on the matter은 진공 상태에서 현상되지 않아야합니다. 자주 병합하고 함께 작업하는 다른 개발자와 의견을 나눕니다.

사우스 팀 코디네이션을 대체 할 수 없습니다 [...] 팀원이 누가 어떤 작업을하는지 알기 때문에 동시에 DB의 동일한 부분에 영향을 미치는 마이그레이션을 작성하지 않아야합니다.

그 조언이 표면에 실망스럽게 들릴 수도 있지만, 실제로는 원칙이 옳습니다. 마이그레이션과 관련하여 여러 가지 개발자가 동일한 시스템 비트를 동시에 사용하도록하는 것은 결코 좋은 생각이 아닙니다. 시스템의 해당 부분에서 이미 작업중인 동일한 개발자에게 유사한 작업을 할당하면 아무 문제가 없습니다.