NHibernate와 상대적으로 자주 변경되는 스키마에 대한 나의 워크 플로우를 개선하고, 이것을 어떻게 처리해야하는지 궁금합니다. 프로덕션 시스템에 동일한 솔루션을 적용하고 싶습니다. 스키마 업데이트가 아니라 마이그레이션 엔진.nhibernate + 마이 그 레이션 워크 플로우
내가 알고 싶은 것은 도메인 모델과 동기화하여 데이터베이스를 가능한 한 작게 만들기 위해 최대한 워크 플로를 조정할 수있는 방법입니다. 스크립트의 타란티노 접근 방식은 멋지지만 내 nHibernate 매핑에서 업데이트 스크립트를 생성하는 방법이없는 것 같아서 스크립트 작성이나 redgate sql과 같은 도구를 사용하여 직접 작성합니다. 스크립트 생성 단계에서 삶을 편하게 해줄 수있는 것이 누락 되었습니까?
덕분에, 크리스
나는 나 자신이 migration tools for .net 중 하나를 사용하지 않은,하지만 몇 년 전에 내 여가 시간에 루비 온 레일즈을하려고 할 때, 나는 T-SQL에 비해 마이그레이션의 혜택을 보았다 당시 우리 직장에서 사용했던 스크립트.
최근의 프로젝트에서 우리는 VCS 분기와 NHibernate와 결합 된 마이그레이션이 여러 가지 골칫거리와 단점을 초래할 수 있다는 것을 발견했습니다.
우리가 한 것은 NHibernate가 일부 자동화 된 빌드 (개발 환경 용)와 함께 일부 데이터로드와 함께 스키마를 생성하도록 설정하는 것이 었습니다.
프로덕션 환경에서는 현재 스키마와 원하는 스키마를 기반으로 필요한 필드와 수정 사항이있는 마이그레이션을 생성했습니다.
이 dev-to-production 스크립트의 생성을 자동화 했습니까? –
SQL Compare을 사용합니다. 그것은 돈을 지불하지만 가치가 투자 imho. 생성 된 각 스크립트를 잘 정리 된 상태로 유지하십시오 (예 : 타임 스탬프). 출시 된 모든 버전의 데이터베이스를 생성하는 좋은 방법입니다.
이것은 우리가 두 개의 데이터베이스 "프로젝트 이름"과 "ProjectName_TEST"가 DEV 동안 우리의 일반적인 흐름
VS 빌드 이벤트를 통해 프로세스를 자동화하는 것이 매우 편리하기 때문에 command line options을 살펴보십시오.
귀하의 제안에 감사드립니다,하지만 내 질문은 더 많은 도구를 사용할 수있는 것보다 워크 플로우를 최적화하는 것이 었습니다 ... – Chris