데이터베이스 스키마를 업그레이드하면 새 소프트웨어 릴리스를 설치하는 것이 훨씬 번잡합니다. 이 작업을 수행하는 가장 좋은 방법은 무엇입니까? 데이터베이스 스키마 업그레이드 검사 목록
,
등 위험 및 가동 중지 시간을 최소화하는 방법을 보여줍니다. 이러한 데이터베이스를 프로덕션 서버에 테스트 어플의 개발자의 홍보
특히 관심이다.
나는 이것에 많은 경험이있다. 내 응용 프로그램은 매우 반복적이며 스키마 변경은 자주 발생합니다. 대략 2 ~ 3 주마다 프로덕션 릴리스를 수행하며 각 항목에 대해 FogBugz 목록에서 50 ~ 100 개의 항목을 지 웁니다. 지난 몇 년간 우리가 해왔 던 모든 릴리스에는 새로운 기능을 지원하기위한 스키마 변경이 필요했습니다.
실제 서버에서 변경하기 전에 테스트 환경에서 변경 사항을 여러 번 연습하는 것이 핵심입니다.
서식 파일에서 복사 된 다음 배포본마다 자주 변경되는 배포 체크리스트 파일을 보관합니다.
나는 데이터베이스에서 실행되는 두 개의 스크립트를 가지고 있는데, 하나는 스키마 변경을위한 것이고 하나는 프로그래밍 가능성 (프로 시저, 뷰 등)을위한 것입니다. 변경 스크립트는 손으로 코딩되며 procs가있는 스크립트는 Powershell을 통해 스크립팅됩니다. 변경 스크립트는 모든 기능이 꺼져있을 때 실행됩니다 (이 경우 가장 적은 양의 사용자를 괴롭히는 시간을 선택해야합니다). 그리고 이상한 일이 생길 때를 대비하여 수동으로 명령으로 명령을 실행합니다. 가장 일반적인 문제는 중복 행으로 인해 실패한 고유 제한 조건을 추가하는 것입니다.
통합 테스트주기를 준비 할 때 테스트 서버의 체크리스트를 살펴 봅니다. 그런 다음, 프로덕션 데이터베이스의 실제 복사본을 얻습니다 (이것은 오프 사이트 백업을 스왑하는 좋은시기입니다). 그리고 복원 된 로컬 버전에서 스크립트를 실행합니다. 최신 백업은 소리입니다). 나는 돌 하나를 가지고 많은 새를 죽이고있다.
는 그래서 4 데이터베이스 총입니다.
. 스키마 변경을 백업하는 것은 어렵습니다.
핫픽스에 관한 한, 매우 고립 된 변화이고 비즈니스에 결정적이지 않은 한, 핫픽스는 프로 시저가 아닌 스키마 만 제공합니다.
난 당신이 (가) 스콧 느리게 걷는 사람의 읽고 생각 한 생각? http://www.agiledata.org/essays/databaseRefactoring.html
이 난 그냥 직장에서 얘기 한 주제입니다. 주로 문제는 데이터베이스 마이그레이션이 레일 프레임 워크와 마이그레이션 스크립트와 같은 프레임 워크에 의해 잘 처리되지 않는 한 당신에게 달려 있다는 것입니다. 우리가 할
현재의 방법은 명백한 결함을 가지고, 나는 다른 제안에 열려입니다.
이것은 결코 최적이 아니며 실제로 "백업"db로 사용되지 않습니다. 간단하게 살기 위해 노력하고 개발자를 같은 페이지로 유지하는 것입니다. db에 SQL 파일의 응용 프로그램을 자동화하는 것과 같이 아마도 capistrano로 설정할 수있는 멋진 것이있을 것입니다.
DB 특정 버전 제어 꽤 좋지 않을까. 아마 그 일을하는 무언가가있을 것입니다.
그리고 스콧 느리게 걷는 용지가 식욕을 돋 웁니다 만약 내가 프라 모드 J Sadolage 그의 책을 추천 할 수있다 '는 리팩토링 데이터베이스'라는 - http://www.ambysoft.com/books/refactoringDatabases.html
유용한 조언과 정보를 많이 야후의 민첩한 데이터베이스 그룹에서도있다 - http://tech.groups.yahoo.com/group/agileDatabases/
두 빠르게 메모 :
그것은 간다 ... 말없이 그래서 내가 두 번 말할 것이다.
유효한 백업인지 확인하십시오.
유효한 백업인지 확인하십시오.
@mk. 데이터베이스 버전 관리에서 Jeff's blog post 체크 아웃 (아직 로그인하지 않은 경우)