상황 : dba는 전체 DAL 코드를 TFS에서 체크 아웃 상태로 유지하는 오프 사이트 계약자입니다. 프런트 엔드 개발자는이 친구가 이메일을 통해 작업을 수행 할 때까지 기다릴 필요없이 열을 추가하고 프로세스 및 기타 사항을 조정할 수있는 것이 좋을 것입니다.
질문 : 팀 전체의 평화 사랑과 행복뿐만 아니라 데이터 무결성을 유지하면서보다 신속하고 민첩한 개발을 가능하게하는 권장 솔루션 / 프로세스는 무엇입니까?
상황 : dba는 전체 DAL 코드를 TFS에서 체크 아웃 상태로 유지하는 오프 사이트 계약자입니다. 프런트 엔드 개발자는이 친구가 이메일을 통해 작업을 수행 할 때까지 기다릴 필요없이 열을 추가하고 프로세스 및 기타 사항을 조정할 수있는 것이 좋을 것입니다.
질문 : 팀 전체의 평화 사랑과 행복뿐만 아니라 데이터 무결성을 유지하면서보다 신속하고 민첩한 개발을 가능하게하는 권장 솔루션 / 프로세스는 무엇입니까?
답변:
Martin Fowler와 Pramod Sadalage는 이 주제에 대해 훌륭한 기사 를 썼습니다 .
모든 개발자는 자신의 데이터베이스를 변경하여 변경할 수 있습니다. 이러한 변경 사항은 마스터 데이터베이스에서 변경 사항을 구현하는 DBA에 변경 변경 사항으로 다시 전달되므로 프로세스에 여전히 관여하고 있으므로 데이터베이스의 구조와 요구 사항에 대해 가장 잘 알고있을 것입니다. 프로세스에 관련된 모든 사람들에게 만족스럽고 매우 민첩하기 때문에 이것이 최선의 방법이라고 생각합니다.
비슷한 방식으로 DAL을 변경할 수 있습니다. 당신이 끝났다고 생각 될 때 변경하고 DBA에 대한 변경 세트를 제공하기 만하면 DBA가이를 검토하고 그의 마스터로 병합 할 수 있습니다.
Wellll, 내가 DBA 일을 할 때, 나는 지저분한 더러운 프로그래머가 자신의 미트를 얻을 수 없도록 모든 것을 잠그는 것으로 알려져 있습니다. 모든 사람들은 자신이 더 잘하는 방법을 알고 있다고 생각하고 스스로 더 쉽게 만들 수 있도록 "비틀어"부정한 혼란을 야기합니다.
다른 대안은 그것을 넓게 열어 놓고 프로그래머가 잠시 동안 근접하게 한 다음 물건이 가까이 다가 가기 시작할 때 뛰어 들어 순서를 부과하는 것입니다. 잘려 지거나 변경되어야하는 것에 따른 실제 악몽 ... DBA는 종종 프로젝트 전체를 더 잘 이해하며, 무해한 일부 변경은 문제가 될 수 있습니다.
그가 유일한 게이트 키퍼가 되려면 고정 된 사양을 갖추거나 비전을 다른 개발자들에게 "판매"할 수 있어야합니다.
간단하지만 아직 3 가지 환경이 있어야합니다.
개발 환경은 개발자가 관리해야합니다.
RC 환경을 추가 할 수도 있습니다.
또 다른 대답은 여러 환경이 불가능한 경우 모의 저장소를 기반으로 개발할 수 있다는 것입니다. 이렇게하면 모델을 구축 한 다음 계약자가 모델을 DB와 일치시킬 책임이 있습니다. 어떤 식 으로든 개발자가 데이터베이스에 대해 걱정할 필요가 없으므로 더 좋습니다.