아직 Commerce Server 및 개발자 도구에 익숙하지 않습니다. 판매되는 물건을 보유하기 위해 DB가 포함되어 있음을 이해합니다. 하나의 테스트 서버와 여러 개의 dev 워크 스테이션이있는 곳에 dev 인프라를 설치하고 DB를 공유하도록합니다. 또한 CVS 저장소가있는 별도의 서버가 있고 여러 사람이 수동으로 CVS 서버에서 가져 와서 작업하고 체크인하는 경우가 있습니다. 테스트 서버의 빌드 및 배포 도구는 CVS에서 가져오고 테스트 서버에 전개하십시오. 내 관심사는 공유 DB이고, 각 dev 워크 스테이션은 자신의 DB가 필요합니까? 다중 devs, 하나의 테스트 서버 및 소스 제어 시스템을 가장 잘 처리하는 방법에 대한 일반적인 개요를 찾고 있습니다.소스 제어를 사용하는 Websphere Commerce dev 설치
나는 데이터베이스를 공유하려고하지는 않으나 모든 개발자 환경이 다른 개발자 변경 사항 (DB에서)을 무시할 수 있으므로 좋은 생각이라고 생각하지 않습니다.
그리고 개발자가 데이터베이스 구조를 수정해야하는 경우 모든 사람에게 피해를 줄 수 있습니다.
각 dev 환경에 데이터베이스가있는 것이 좋으며 테스트 환경과 동일 할 필요는 없습니다.
테스트 서버용 빌드 및 배포에 적합합니다.
팀 규모에 따라 다릅니다. 대부분의 소규모 프로젝트에서 팀원 모두가 자신의 DB를 가지고 있고 특히 DB가 Derby/Cloudscape 인 경우 DB2 또는 Oracle을 사용하는 큰 프로젝트의 경우 다른 머신에 저장된 공유 DB를 사용하는 것이 좋습니다 모든 사람의 로컬 컴퓨터보다 한 사람이 데이터를 삭제해도 공유 된 컴퓨터로 인해 문제가 발생할 수 있지만 작은 백업 만 있으면 해결 될 수 있습니다. 팀의 모든 직원이 자신의 DB를 가지고 있다면 리드는 모든 사람의 DB가 (일상적인 작업 인 CVS에서 코드를 매번 동기화 할 때마다 워크 스테이션을 작동시키기 위해 모든 사람의 컴퓨터에서 실행해야하는 작은 업데이트 sql)
이렇게 할 수 있습니다. IBM은 해당 구성을 지원합니다. 대부분의 개발자는 WCS Developer와 함께 제공되는 내장 된 WCS 환경을 사용합니다. 그것은 Apache Derby와 함께 런타임을 데이터베이스로 갖는다.
또한 IBM 제품 전문가와상의 할 것을 권장합니다. 그들은 당신에게 모범 사례를 말할 수 있으며 소프트웨어 구입의 일환으로 그에게 접근 할 수 있습니다. PMR을 열고 질문하십시오.
각 개발자마다 로컬 데이터베이스를 사용하십시오.
그런 다음 데이터베이스 구조 변경을 관리하기 위해 liquibase와 같은 것을 사용하십시오. 모든 데이터베이스 변경 내용을 스크립팅하고 소스 저장소에 배치 한 다음 저장소 프로젝트에 liquibase 서블릿을 추가하십시오. 그렇게하면 개발자가 새로운 것을 체크 아웃 할 때 서버를 다시 시작할 때 로컬 데이터베이스가 자동으로 업데이트됩니다.
SQL 스크립트가 실제로 팀의 개발자보다 한 번 이상 테스트를받는 이점이 있습니다.
이제는 개발자에게 wcbd를 사용하는 것이 가장 이상적입니다. 그러나이 스크립트는 이미 시스템에서 실행 된 스크립트를 추적하지 않기 때문에 수퍼 Defensive SQL 스크립트 (이 테이블에 이미 X 문자가 Y 열로 확장되어 있는지 확인)를 작성하는 것이 매우 어렵습니다. dataload를 사용하면 실제로는 안되는 것을 무효화 할 수 있습니다.