EF 마이그레이션으로 프로덕션 데이터베이스를 업데이트해도됩니까?

EF 마이그레이션으로 프로덕션 데이터베이스를 업데이트해도됩니까?

---

이 블로그 게시물 에 따르면 EF 마이그레이션을 사용하는 대부분의 회사는 EF 마이그레이션으로 프로덕션 데이터베이스의 데이터베이스 스키마를 업데이트하지 않는 것으로 보입니다. 대신 블로그 게시물의 작성자는 배포 프로세스의 일부로 스키마 업데이트 스크립트를 사용할 것을 권장합니다.

지금까지 몇 년 동안 스키마 업데이트 스크립트를 사용해 왔으며 작동하는 동안 다음과 같은 이유로 향후 대신 EF 마이그레이션을 사용할 계획이었습니다.

• 더 빠른 배포, 더 적은 다운 타임
• 더 간단한 배포 절차
• T-SQL을 사용하는 것보다 훨씬 쉽게 기존 데이터 마이그레이션
• 적용 대기중인 변경 사항에 대한보다 이해하기 쉬운 구문 (깨끗한 C # 구문을 사용하는 DbMigration 클래스와 기존 환경의 투박한 T-SQL 마이그레이션 스크립트)
• 새 소프트웨어 버전의 배포가 실패 할 경우 이전 db 스키마에 대한 쉽고 빠른 다운 그레이드 경로가 있습니다.

EF를 사용하여 프로덕션 DB를 마이그레이션하는 것을 금지한다고 생각할 수있는 한 가지 이유는 DB 스키마가 개발자가 아닌 DBA에 의해서만 변경된 경우입니다. 그러나 저는 DBA이자 개발자이므로 제 경우에는 중요하지 않습니다.

그렇다면 EF를 사용하여 프로덕션 데이터베이스를 업데이트하면 어떤 위험이 있습니까?

편집 : solomon8718이 이미 제안했듯이 항상 프로덕션 데이터베이스의 새 복사본을 스테이징 서버로 가져오고 프로덕션 서버에 적용하기 전에 스테이징 서버에 적용될 EF 마이그레이션을 테스트합니다. IMO는 EF 마이그레이션을 사용하는지 여부에 관계없이 프로덕션 시스템에 대한 스키마 업데이트에 필수적입니다.

---

글쎄, 나는 어쨌든 대답 할 것이다. 아니요, 프로덕션에서 Code First 마이그레이션을 사용하지 않을 이유가 없습니다. 결국, 당신이 그것을 끝까지 가져갈 수 없다면이 사용하기 쉬운 시스템의 요점은 무엇입니까?

내가 본 가장 큰 문제는 이미 언급 한 모든 시스템에서 발생할 수있는 모든 문제입니다. 전체 팀 (해당되는 경우 DBA 포함)이 함께하는 한, EF가 마이그레이션을 통해 스키마를 관리하도록 허용하는 것은 덜 복잡하고 기존 스크립트 기반 관리보다 오류 발생 가능성이 적다고 생각합니다. 프로덕션 시스템에서 마이그레이션을 수행하기 전에 백업을 수행 하겠지만 어쨌든 그렇게 할 것입니다.

DBA가 Visual Studio에서 마이그레이션을 수행 할 수 없다는 내용도 없습니다. 액세스는 데이터베이스 수준의 권한으로 여전히 잠길 수 -Script있으며 실제 작업을 수행하기 전에 마이그레이션을 검토 할 수 있습니다 ( 원하는 경우를 사용하여 유용한 SQL 내보내기 형식으로 ). 그런 다음 여전히 제어 할 수 있지만 코드 우선 마이그레이션을 사용할 수 있습니다. 지옥, 그들은 그것을 좋아하게 될 수도 있습니다!

업데이트 : sprocs가와 TVFs이 제기 된 이후 그들이 실제로 사용 스트레이트 업 SQL 문으로 수행하고 있지만, 우리는뿐만 아니라 마이그레이션에 그 처리 DbMigration.Sql()에 전화 Up()하고, 그들의 역 Down()(또한 사용할 수 있습니다 CreateStoredProcedure및 DropStoredProcedure간단한를 들어 SPROCs,하지만 SQL에서 본문 자체를 정의해야한다고 생각합니다.) 나는 그것이 경고라고 말할 수 있다고 생각합니다. 전체적이고 포괄적 인 데이터베이스를 순수하게 C #으로 작성할 수있는 방법은 아직 없습니다. 그러나 SQL 스크립트가 포함 된 마이그레이션을 사용하여 전체 스키마를 관리 할 수 있습니다. 이 프로세스에서 찾은 한 가지 이점은 스키마 개체 이름에 대해 C # 구성 파일을 사용할 수 있다는 것입니다 (예 : 프로덕션과 개발의 다른 서버 이름).String.Format, 구성 파일 자체에 대한 XML 변환과 결합됩니다.

---

예, 프로덕션 데이터베이스를 변경 하기 위해 Code First Migrations와 같은 자동화 된 시스템을 사용 하지 않는 좋은 이유 가 있습니다 . 그러나 항상 그렇듯이 규칙에는 예외가 있습니다.

1. 언급 된 한 가지 이유는 조직의 변경 관리 규칙 및 보안 정책과 직접적으로 관련된 액세스 권한입니다.

2. 또 다른 이유는 마이그레이션 도구 자체에 대한 신뢰 수준입니다. 도구에 버그가없는 것이 확실합니까? 도구가 중간에 실패하면 어떻게됩니까? 최신 백업이 있고 필요한 경우 롤백 할 프로세스가 있습니까?

3. 변경 스크립트는 예기치 않거나 비효율적 인 스크립트를 실행할 수 있습니다. 나는 SQL이 생성 한 데이터를 임시 테이블에 복사하고 원래 테이블을 삭제 한 다음 실수로 (또는 의도적으로) 열이 나타나는 순서를 변경 한 경우 새 열을 추가하는 것과 같은 작업을 위해 원래 테이블을 다시 만든 경우를 경험했습니다. 또는 테이블 이름을 바꿀 때. 수백만 개의 레코드가 관련된 경우 심각한 성능 문제가 발생할 수 있습니다.

내 추천 :

프로덕션 스키마를 미러링하는 스테이징 데이터베이스가 있다고 가정하면 마이그레이션 도구를 사용하여 해당 시스템에 대한 변경 스크립트를 생성하십시오. 일반적으로 실행하기 전에 새로운 프로덕션 복사본에서 스테이지 데이터베이스를 복원합니다. 그런 다음 변경 스크립트를 수동으로 검사하여 문제를 확인합니다. 그런 다음 스테이지 데이터베이스에 대해 스크립트를 실행하여 제대로 실행되고 예상되는 모든 변경 사항이 발생했는지 확인합니다. 이제 스크립트가 프로덕션 환경에서 안전하게 실행되고 예상되는 변경을 수행 할 수 있음을 확신합니다. 이 프로세스는 위에 나열된 세 가지 문제를 모두 해결합니다.

---

내가 발견 한 또 하나의주의 사항 : 동일한 데이터 컨텍스트를 사용하는 여러 웹 사이트가있는 경우 모든 웹 사이트가 동시에 업데이트되는지 확인해야합니다. 그렇지 않으면 웹 사이트간에 지속적인 데이터베이스 업데이트 / 다운 그레이드 싸움이있을 수 있습니다. 그 외에는 잘 작동했습니다.

편집 : 프로덕션에서 EF 마이그레이션을 사용하기 시작한 지 1 년 후 내 관점 :

EF 마이그레이션은 실제로 프로덕션 용도로도 매우 멋집니다.

1. 스테이징 시스템에서 마이그레이션을 테스트하십시오. 통합 테스트를 실행하기 전에 CI 서버에서 위아래로 완전히 마이그레이션하여 모든 마이그레이션을 테스트합니다.
2. 마이그레이션을 자동으로 트리거하지 말고 관리자가 시작한 배치 파일을 사용하십시오. 이것은 본질적으로 SSMS에서 수동으로 마이그레이션을 위해 SQL을 실행하는 것과 동일합니다.

---

몇 가지 프로젝트를 위해 프로덕션에 사용합니다. 요령을 이해하면 괜찮다고 생각합니다.

개발 중에 자동 마이그레이션을 유지할 수 있지만 마지막에는 패키지 관리자 콘솔에서 라이브 DB에 직접 연결하여 마이그레이션을 생성 할 수 있습니다. 모든 변경 사항에 대해 하나의 마이그레이션을 제공합니다.

그러나 항상 항상 -script옵션을 사용 update-database하고 SQL을 직접 실행하십시오.

또한 웹 배포에서 업데이트 db 옵션을 사용하지 않는 것이 좋습니다. 이렇게하면 이미 오류로 인해 발생한 마이그레이션의 양을 알 수있는 방법이 없습니다. 나는 몇 번 문제를 겪었습니다. 따라서 SQL을 가져와 수동으로 실행하는 것이 가장 좋습니다.

참고 URL : https://stackoverflow.com/questions/29746937/is-it-ok-to-update-a-production-database-with-ef-migrations