저는 현재 모두 하나의 개발 데이터베이스에 연결되어있는 웹 프로젝트에서 작업하고 있습니다.더 나은 개발 데이터베이스 구성 방법을 제안하십시오
다른 중앙 집중식 시스템과 마찬가지로이 데이터베이스는 시간이 지나면 단일 실패 지점으로 판명됩니다.
개발자 중 일부가 부주의하게 데이터베이스에 더티 데이터를 덤프하는 경우 다른 모든 개발자가 부작용을 겪습니다.
우리는 아마 우리 모두가 원래 데이터베이스의 복사본을 만들고 로컬 데이터베이스에 연결하기 위해 웹 응용 프로그램을 설정해야한다고 생각합니다.
필자의 경우, 팀의 핵심 구성원은 5 명의 개발자, 하나의 테스터 (주로 블랙 박스 테스트)입니다. 개발 프로세스는 다음과 같이 진행됩니다. 각 개발자는 하나의 하위 기능을 담당하고 자체 지점에서 작업 한 다음 해당 지점을 테스터가 응용 프로그램을 테스트하는 트렁크에 병합합니다.
제발 나에게 몇 가지 제안.
모든 사람이 데이터베이스의 별도 사본에서 개발하는 데 문제는 다른 개발자의 변경 사항을 선택하지 않는다는 것입니다.
예를 들어 누군가 데이터베이스 테이블에 열을 추가하면 다른 개발자는이를 인식하지 못합니다. 다른 사용자가 실수로 동일한 열을 추가 할 수도 있습니다.
누군가가 (예를 들어 입력 매개 변수를 추가하기 위해) 앱 코드를 변경해야하는 방식으로 저장 프로 시저를 변경하면 다른 개발자는이를 알 수 없습니다. 소스 컨트롤에서 업데이트 된 코드를 가져 오면 로컬 데이터베이스 복사본에서 작동하지 않습니다.
나는 점점 더 혼란스러워 진 개발 데이터베이스가 문제가된다는 데 동의합니다. 그러나 데이터베이스의 여러 복사본을 개발하면 개발 문제의 수를 줄일 수 있을지 확신하지 못합니다.
제가 알고있는 대안 중 하나는 프로덕션 데이터베이스를 주기적으로 개발에 복사하는 것입니다. 일반적으로 이것은 프로덕션 데이터베이스 스키마에 필요한 모든 변경 사항을 수행하는 새 릴리스 이후에만 발생할 수 있습니다. 그러나이를 위해서는 프로덕션 데이터베이스가 있어야합니다.
개인적으로 개발자 변경 사항을 동기화하는 것이 더 쉬운 것으로 나타났습니다. 코드 변경과 함께 충돌이 발생하지 않도록 대화 할 필요가 있습니다. 단일 인스턴스에 대해 비동기 코드로 작업하는 여러 사람이 시도하는 것보다 쉽습니다.큰 수준의 세밀한 수준에서 코드/db 동기화를 강요하면 개별 DB를 일치시키기 위해 항상 로컬 코드 복사본을 계속 업데이트해야하는 경우보다 각자의 작업 속도가 빨라지는 것처럼 보입니다. 필자는 매일 두 번 매주, 반복마다 (최악의 경우) 통합하는 방법에 대해 설명합니다. 나는 변화가 너무 멀리 내버려 두지 않는다. – tvanfosson
데이터베이스의 로컬 복사본이 있다는 단점에 동의합니다. 어쩌면 이것은 최선의 방법을 찾는 대신 문제 자체에 집중함으로써 해결 될 수있는 종류의 문제 일 수 있습니다. – satoru
레드 게이트 (내가 일하는 사람)는 SQL 소스 제어 (http://www.red-gate.com/Products/SQL_Source_Control/index.htm)라는 제품으로 바로이 문제를 해결할 것입니다. 몇 달 동안은 나오지 않지만 개발자 데이터베이스를 SQL Compare와 동기화 할 수 있습니다. –
내 프로젝트에서 개발 데이터베이스는 항상 개발자 로컬 컴퓨터에 있습니다. 우리는 SQL Server Developer Edition 또는 SQL Server Express를 사용합니다. 우리는 소스 코드 저장소에 체크 인 된 DB를 생성하기위한 SQL 스크립트를 유지합니다. 로컬 DB를 다시 만들 필요가있는 사람이라면 누구나 이것을 사용할 수 있습니다. 한 팀 구성원이 SQL 스크립트를 유지 관리해야하며 모든 데이터베이스 변경 내용이 먼저 사용자에게 전달됩니다 (일반적으로 SQL 스크립트). 그는 SCM에서 스크립트의 최신 버전을 가져 와서 로컬 복사본을 업데이트하고 SCM의 스크립트를 대체하는 업데이트 된 생성 스크립트를 생성합니다. 동시에 코드를 변경하면 코드와 DB가 동기화되도록 SCM으로 점검됩니다. 다른 모든 사람들이이 버전과 동기화됩니다.
이것은 사람들에게 병렬로 작업 할 수있는 자유를 주며, 실험 변경 사항을 포함하여 필요에 따라 스키마를 변경할 수 있습니다. 또한 로컬 DB를 웹 응용 프로그램의 로컬 테스트를위한 더미 데이터의 소스로 사용합니다. 단위 테스트가 아닌 일반적으로 DB를 모의하지만 통합 및 UI 테스트입니다. 로컬 데이터베이스를 별도로 유지하면 각 개발자는 다른 사용자와의 조정없이 필요에 따라 테스트를 설정할 수 있습니다.
우리는 Red Gate's SQL Compare를 사용하여 코디네이터의 로컬 DB가 공식 체크인 버전에있는 경우 변경 사항을 적용하도록 언급해야합니다.이는 DB를 삭제하고 다시 만드는 대신에 기존 데이터를 보존하는 데 훨씬 효과적입니다. DB 변경 사항에 따라 이는 사소하거나 다소 복잡한 작업 일 수 있습니다. 변경 사항이 손으로 (실수없이) 작성 될 수있는 경우를 제외하고는 항상 QA/테스트 및 프로덕션 DB를 업데이트하는 데 사용합니다.
나는 비교적 작은 팀에 항상 있었다고 말할 수있는 자격이 있어야합니다. 나는 그것이 더 큰 팀 (팀의 팀?)에게 확장되거나 적응할 수있을 것이라고 생각 하겠지만, 나는 그것에 대해 직접적인 경험이 없다. – tvanfosson
내 회사에서 잘 작동하는 솔루션은 각 개발자를 위해 가상 컴퓨터에서 데이터베이스를 실행하는 것입니다.
우리가 지원하는 각 데이터베이스 (oracle, db2, mssql, mysql)에 대해 하나의 가상 시스템을 설정했습니다. 이제 모든 개발자는 가상 컴퓨터를 설치하지 않고도 로컬 컴퓨터에서 간단하게 복사하고 실행할 수 있습니다.
각 개발자가 유닛 테스트를 실행할 때마다 플러시되고 재구성되며 테스트 데이터로 채워지는 자체 데이터베이스가있는 시스템을 설정하는 것이 매우 도움이된다는 것을 발견했습니다. 이 방법으로, 당신은 서로의 방식으로있을 수 없습니다. 물론 지속적인 통합 및 테스트 서버에는 자체 데이터베이스가 있어야합니다.
DDL 및 테스트 데이터가 버전 제어에 있어도 모든 사용자가 동일한 데이터베이스에 대해 작업하고 있습니다. 또 다른 장점은 DB 변경이 필요한 기능을 개발할 때 모든 사람이 해당 변경에 필요한 코드와 DDL + 테스트 데이터를 모두 얻을 수 있다는 것입니다.
자바 영역에서 우리의 경우 DbUnit은 Hibernate Maven 플러그인과 함께 매우 유용합니다. 물론 간단한 자작 해결책이 유용 할 수도 있습니다.
우리는 다른 사람들이 여기에서 설명한 것과 거의 동일한 기본 프로세스를 사용합니다. 몇 가지 중요한 변경 사항이 있습니다. 각 개발자는 일반적으로 자체 db 인스턴스를 가지고 있으며 변경 스크립트를 사용하여 관리합니다. 세부 사항은 다음과 같습니다.
스키마 변경 스크립트의 파일 이름에 인코딩 된 버전 번호가 있어야하며 두 개발자가 모두 동일한 버전 스크립트를 만들면 충돌이 발생할 수 있기 때문에 포인트가 조금 엉켜 있습니다. 그리고 일관성없는 상태에있는 db를 가질 수 있고 자동화 된 프로세스가 실패 할 때가 있습니다. 그러나 전반적으로 그것은 우리를 위해 아주 잘 작동했습니다.
회사 규모는 어느 정도입니까? 개발자, 테스트 및 프로덕션 환경을 갖추고 있습니까? 전용 테스트 팀이 있습니까? 많은 변수가 있으며 이는 매우 광범위한 질문입니다. –