데이터베이스 파일 (스크립트 등)이 소스 제어에 있어야합니까? 그렇다면 유지하고 업데이트하는 가장 좋은 방법은 무엇입니까?

모든 사람이 데이터베이스를 사용하고 필요할 경우 변경할 수있는 개발 서버에 데이터베이스 파일을 배치 할 수 있기 때문에 데이터베이스 파일이 소스 제어에 있어야합니까? 그러나 누군가 엉망으로 만들면 되돌릴 수 없습니다.

소스 제어의 데이터베이스에 가장 적합한 방법은 무엇입니까?

예. 데이터베이스를 포함한 소스 제어에서 시스템의 일부를 다시 빌드 할 수 있어야합니다 (또한 특정 정적 데이터를 주장합니다).

도구를 만들고 싶지 않다고 가정하면 다음을 포함하고 싶습니다.

• 스키마, 사용자, 테이블, 키, 기본값 등을 포함한 기본 테이블 구조용 작성 스크립트
• 업그레이드 스크립트 (테이블 구조 변경 또는 이전 스키마에서 새 스키마로 데이터 마이그레이션)
• 저장 프로 시저, 인덱스, 뷰, 트리거를위한 ​​생성 스크립트 (올바른 생성 스크립트를 사용하여 있던 내용을 덮어 쓰므로 업그레이드에 대해 걱정할 필요가 없습니다)
• 시스템을 실행하기위한 데이터 생성 스크립트 (단일 사용자, 정적 선택 목록 데이터 등)

모든 스크립트는 적절한 drop 문을 포함해야하며 모든 사용자로 실행할 수 있도록 작성해야합니다 (해당되는 경우 관련 스키마 / 소유자 접두사 포함).

업데이트 / 태그 지정 / 분기 프로세스는 나머지 소스 코드와 동일해야합니다. 데이터베이스 버전을 응용 프로그램 버전과 연결할 수없는 경우에는 수행 할 점이 거의 없습니다.

또한 사람들이 테스트 서버를 업데이트 할 수 있다고 말하면 개발 서버를 의미하기를 바랍니다. 개발자가 즉시 테스트 서버를 업데이트하는 경우 릴리스해야 할 작업을 수행 할 때 어려움을 겪고 있습니다.

예.

그것을 유지하고 업데이트하는 가장 좋은 방법은 무엇입니까?

음 스키마 빌더 스크립트를 작성하십시오. 변경 후 확인하십시오. 실행하기 전에 확인하십시오.

원하는 것을 결정하기가 어렵습니다.

공식 스키마 마이그레이션 스크립트를 작성하십시오. 테스트 후 확인하십시오. 실행하기 전에 확인하십시오.

더 무엇입니까?

스키마가 문서화되지 않은 일련의 변경 사항을 통해 유기적으로 발전하기 때문에 스키마 변경이 심각한 문제로 바뀝니다.

이 유기적 진화는 거기에 있어야 할 것에 대한 "권한있는"소스가 없기 때문에 스키마 마이그레이션을 더 어렵게 만듭니다. 준비 버전, QA 버전 및 8 개의 개발 버전의 두 가지 프로덕션 버전이 있습니다. 모두 약간 다릅니다.

신뢰할 수있는 단일 소스가있는 경우 스키마 마이그레이션은 마지막 버전과이 버전 간의 델타입니다.

예

데이터베이스 스크립트 (ddl, dml)는 코드입니다. 모든 코드는 버전 관리 시스템에 있어야합니다.

마이그레이션

• 데이터베이스 마이그레이션 사용

개발, qa 및 릴리스에서 동일한 db 파일을 사용할 수 있습니다.

• 릴리스 번호로 데이터베이스에 릴리스

감사를 위해 릴리스 번호를 어딘가에 저장하십시오. 많은 경우 db 자체에 저장하십시오. 각 릴리스는 데이터베이스를 올바른 버전으로 가져 오는 마이그레이션으로 구성됩니다.

데이터베이스에 소스 제어를 제공하기위한 liquibase 와 같은 도구 가 있습니다. 많은 회사와 마찬가지로 정기적 인 소스 제어 도구에서 변경 / 업데이트 스크립트를 유지 관리하는 것은 번거롭고 항상 데이터베이스를 처음부터 재배치 할 수는 없습니다.

우리는 또한 데이터베이스 비교 도구 (마스터 대 고객 db 비교)를 사용하여 이것을 자동화하려고 시도했지만 도움이되었지만 그러한 도구를 100 % 신뢰할 수는 없으며 검토 프로세스도 필요합니다.

예

게다가, 당신은 가지를 원할 것 입니다.

분기에 Git을 사용합니다.

• 기능별 개발 용 (나머지 애플리케이션의 정기적 인 개발과 마찬가지로)

• 및 프로덕션 서버에 대해 하나 뿐만 아니라 때문에 응용 프로그램을 사용하는 고객도 내용을 만들 수 있습니다.

이렇게하면 소스 코드와 데이터베이스 (및 기타 파일)에 대한 소스 제어 및 분기의 이점을 얻을 수 있습니다.

아직 올인원 시스템을 찾지 못했습니다 [PostgreSQL 용]. 브랜치를 병합 할 때 올바르게 인덱스를 다시 작성하기위한 함수 / 스크립트를 작성해야했습니다 (예 : 고객이 그에 의존하기 때문에 프로덕션 브랜치의 인덱스를 수정해서는 안 됨) 프로덕션 컨텐츠와 교차하는 개발 브랜치의 인덱스 + 외래 키는 다시 인덱싱해야합니다. 모든 응용 프로그램에서 작동하지는 않지만 응용 프로그램의 모든 경우를 다루므로 충분합니다).

그러나 일반적인 아이디어는 데이터베이스 컨텐츠가 애플리케이션의 필수 부분이며 모든 자원이 소스 제어에 있어야한다는 것입니다. 예, 데이터베이스에 대해서도 소스 제어를 사용해야합니다.

Java의 경우 팀은 Flyway 를 사용하는데, 사용하기 쉽고 강력합니다.

Ruby에서 작업하는 경우 Rails에는 마이그레이션 이 있으며이 문제를 처리하는 강력한 방법이기도합니다.

Liquibase 는 이미 언급되었지만 좋은 솔루션이지만 Flyway와 같은 대안보다 더 성가신 것으로 나타났습니다.

또한 RedGate 소프트웨어는 SQL Server 용으로 설계된 SQL Source Control 이라는 제품을 제공합니다 . 나는 그것을 직접 사용하지는 않았지만 동료 중 한 명이 훌륭하다고 말합니다.

개발 데이터베이스에 버전 관리 또는 변경 관리가없는 경우에 여러 번 본 문제가 있습니다. 프로그래머 A는 테이블, 뷰 또는 proc를 변경합니다. 프로그래머 B는 같은 것을 변경하고 프로그래머 A가 한 일을 덮어 씁니다. 또는 DBA는 프로덕션 DB를 개발로 복원하고 변경 사항을 덮어 씁니다. 나는 이런 종류의 물건이 많은 슬픔을 일으키는 것을 보았으므로 너무 재미 있지 않습니다. 그리고 이것은 개발 시스템에만 있습니다. 스테이징 / 테스트 할 때 상황이 매우 어려워 질 수 있으며 프로덕션 서버조차도 이에 걸리게됩니다.

데이터베이스 버전 관리가 일반 코드 버전 관리와 동일 할 필요는 없습니다. 그러나 어떤 종류의 변경 제어 및 기록 백업은 많은 문제를 방지합니다.

"소스 제어"가 아닌 "버전 제어"로 생각하십시오. 이는 특정 스크립트의 전체 기록을 볼 수 있음을 의미합니다. 데이터베이스를 현재 형식으로 재 구축 할 수 있는지 여부는 이러한 스크립트와 데이터베이스를 만드는 데 사용되는 프레임 워크에 대한 관행의 문제가 될 것입니다.

PHP / MySQL 프로젝트에서는 Ladder 라는 작은 도구를 사용했습니다 . 시간이 지남에 따라 데이터베이스의 유기적 성장을 촉진하도록 설계되었습니다. 프로젝트의 모든 마이그레이션은 개정 / 소스 / 버전 제어에 저장되며 코드와 함께 추적됩니다.

열 추가 / 변경 / 삭제, 쿼리 실행, 인덱스, 제약 조건 등 추가 / 삭제 등을 지원합니다. 데이터베이스의 상태를 추적하고 누락 된 마이그레이션을 적용합니다. 또한 필요한 마이그레이션을 지정하여 "시간을 거슬러 올라갈 수"있습니다. ( php ladder.php migrate 15)

아, 그리고 최근에 추가 된 것은 데이터베이스 디핑입니다. diff-save명령을 실행하고 데이터베이스에서 일부 열을 추가 및 제거한 후 명령을 실행하십시오 diff. 데이터베이스 상태에 따라 자동으로 생성 된 마이그레이션 코드가 표시됩니다.

DataGrove 는 여기에 언급 된 일부 문제를 해결합니다 ( 예 : jfrankcarr ).

DB의 모든 변경 사항을 추적하고 전체 DB 상태 버전을 리포지토리에 저장할 수 있습니다. 그런 다음 동일한 DB의 여러 가상 사본을 생성 할 수 있으므로 각 개발자 또는 DBA는 고유 한 사본을 가질 수 있습니다 (각 가상 사본은 다른 버전에서 생성 될 수 있음). 아무도 다른 사람의 코드 / 변경 사항을 무시하지 않도록합니다. 각 가상 복사본도 동일한 리포지토리로 추적되므로 모든 DB 상태를 쉽게 공유하고 다시 만들 수 있습니다.

또한 데이터 버전 관리 도구로 사용할 수있는 모니터링 도구를 가져오고 싶습니다. 내가 이야기하는 도구는 MONyog입니다. 실제로는 MySQL 모니터링 도구이지만 약간의 해킹으로 쉽게 데이터 버전 관리로 사용할 수 있습니다.

그러나 더 나아 가기 전에 버전 관리를 위해 데이터베이스 전체를 배치하는 것이 바람직하지 않을 것이라고 인용 할 것입니다. 특정 데이터 세트에 대한 변경 사항을 추적하는 것은 정말 어려운 일입니다.

MONyog에는 특정 데이터 세트의 변경 사항을 모니터 할 수있는 CSO (Custom SQL Objects) 라는 기능 이 있습니다. CSO 추가는 여기 에 설명되어 있습니다 . 이제 MONyog의 모니터 히스토리 섹션에서 일정 기간 동안 변경 사항을 얻을 수 있습니다. 가장 좋은 방법은 HTML 페이지로 시각적 보고서를 제공하는 것입니다. 보고서는 다음과 같습니다