Drupal 사이트에서 공동 개발을 관리하려면 어떻게해야합니까?

Drupal 사이트에서 다른 개발자와 협력하고 있습니다. 우리는 서로 다른 방식으로 들어 가지 않고 동시에 사이트의 다른 부분에서 작업 할 수있는 좋은 방법을 찾기 위해 고심했습니다. 우리는 사이트의 동일한 개발 인스턴스에서 작업을 시도했지만 종종 서로의 발가락을 밟거나 문제가 해결 될 때까지 다른 사람이 계속 작업하는 것을 불가능하게하는 잘못된 코드로 사이트를 중단합니다. 그래서 우리는 별도의 개발 인스턴스로 옮겼습니다. 그러나 이제 우리의 작업을 사이트의 단일 인스턴스로 병합하는 것은 큰 고통입니다. 기본적으로 공유 사본의 모든 항목을 다시 실행합니다.

현재 가장 큰 문제는 데이터베이스 변경 사항을 병합하는 방법과 소스 제어 시스템에 데이터베이스를 포함시키는 방법입니다. 파일은 쉽고, 모든 파일을 추적하고 (git 사용) 작업을 병합하여 필요한 경우 충돌을 해결합니다. 그러나 이것은 실제로 데이터베이스에서 작동하지 않습니다. SQL 덤프를 가져 와서 git 저장소에 포함시킬 수는 있지만 실제로 데이터베이스를 병합 할 수는 없습니다. 기능 모듈은 우리가 다음 버전과 병합 할 수있는 코드로 우리의 데이터베이스 작업의 일부를 내보내셔서, 조금 도움이됩니다. 그러나 모든 기능에 가까이 다가가 기능을 지원하지는 않습니다. 그래서...

• 데이터베이스 변경 사항을 쉽게 병합하기 위해 어떤 단계를 수행 할 수 있습니까?

• 데이터베이스의 버전을 어떻게 조정해야합니까 (덤프 파일을 git에 넣는 것이 좋은 방법입니까)?

• 이러한 문제 중 일부에 도움이되는 모듈이 있습니까?

• 아니면 동일한 사이트 사본에서 작업하는 데 어려움을 겪고 있습니까? (아니요)

편집 : 의견에서 피처로 내보낼 수없는 것들에 대해 논의했으며 그중 하나는 분류법이었습니다. 그것을 다루는 또 다른 질문이 있습니다 .

워크 플로우 변경이지만 라이브 DB의 새로운 덤프 작업에 익숙해 져야합니다. DB를 변경하는 세 가지 방법이 있습니다.

1. 풍모. 이것은 모든 것이 작동하지는 않지만 필요한 많은 것들을 위해 작동합니다.
2. 후크를 업데이트하십시오. 기능이 작동하지 않으면 소유하고있는 모듈의 업데이트 훅에 하드 코딩 할 수 있습니다.
3. 수동 변경. 드물게 사용하십시오. 일부 기능은 기능이나 업데이트 후크에 자연적으로 제공되지 않으며 수동으로 수행하기가 훨씬 쉽습니다. 이것은 최후의 수단이지만 때로는 유일한 해적 방법입니다.

가능하다면. 하루에 여러 번 새로운 덤프를 받고 빌드를 테스트하면 통합 문제가 줄어 듭니다.

나는 비슷한 질문에 대답했고 여기에 귀하의 질문에 대답하기 위해 약간 조정하려고합니다. 필자의 제안은 지속적인 통합 시스템을 사용하여 코드 변경 사항을 자주 (예 : 5 분마다) 체크 아웃하는 개발 / 스테이징 서버가 있다는 것입니다. 따라서 로컬 시스템에서는 한 번에 하나의 기능 요청 / 버그 보고서에 대해서만 작업하며, 작업중인 팀원들과 작업하고 팀원들과 의사 소통 할 수있는 다른 작업과이 작업을 명확하게 설명해야합니다. 다른 버그 추적이 좋습니다.) 그런 다음 정기적으로 변경 사항을 커밋하면 팀원과 마찬가지로 개발자 / 스테이징 서버로 풀다운됩니다. 이상적으로는 지속적인 통합 시스템에 단위 테스트가 내장되어 있습니다 (루앤 빌드 또는 QuickBuild를 권장하지만 허드슨도 작동합니다). CI 시스템 또는 테스트는 코드를 체크인하자마자 발생할 수있는 충돌을 자동으로 해결할 수 있습니다. 컨텐츠 (비 코드)를 변경해야하는 경우 개발자 / 스테이징 서버에서 변경해야합니다.

데이터베이스 부분에 관해서, 나는 기본적으로 여기에 두 개의 사고 학교를 채택했습니다 (데이터베이스 diffs를 수행하는 세 번째 사고 학교는 복잡성이 매우 높기 때문에 논의하지 않을 것입니다).

1) 프로덕션 데이터베이스를 삭제하고 개발 데이터베이스의 mysqldump를 가져 와서 배포하십시오. 선택적으로 SQL 덤프의 dev URL을 참조하는 하드 코딩 된 절대 링크에서 미리 정규식 찾기 / 바꾸기를 실행하십시오. dev db를 prod로 가져온 후에는 자동으로 SQL 문 (일반적으로 스크립트를 통해)을 실행하여 prod와 다른 설정을 변경합니다 (예 : 변수 테이블에 필요한 외부 시스템에 연결하기위한 일부 연결 설정이있을 수 있음) dev 버전이 아닌 prod 외부 시스템을 가리 키도록 변경하십시오.

2) 관리자 설정에는 budda에서 언급 한대로 Features 모듈을 사용하고 Delete All 모듈과 함께 컨텐츠 내보내기 / 가져 오기에는 Node Export 모듈을 사용하십시오. 워크 플로는 다음과 같습니다.

node_export 및 기능을 사용하여 노드 / 기능을 파일로 내보내기 선택적으로 (및 희망적으로) 버전 제어 prod 시스템에 파일로드 drush 또는 admin 인터페이스를 사용하여 기능로드 drush delete-all 또는 admin 인터페이스를 사용하여 가져 오려는 유형의 모든 노드를 삭제하십시오. drush ne-import 또는 관리 인터페이스를 사용하여 내 보낸 노드 파일에서 노드를 가져 오십시오. 한 가지 참고 사항은 콘텐츠가 한 방향으로 만 진행되는 표준 워크 플로를 사용하는 것이 좋습니다. Dev-> Prod 또는 Prod-> Dev 중 하나입니다.

나는 이것을 해왔고 꽤 큰 결과를 얻은 일부 큰 시스템 에서이 작업을 수행하고 있지만 항상이 사과를 얇게 썰고 나에게 가장 적합한 방법을 선택하는 많은 방법이 있습니다.

이것은 대답이 허용되는 오래된 질문이지만 여전히 다른 질문에 대한 여지가 있다고 생각합니다.

먼저 기능 이이 작업에 적합한 도구 라고 생각하지 않으며 대체 도구 세트를 제안합니다.

팀 협업을위한 전제 조건은 프로덕션 서버와 별도의 프로젝트 개발 버전을 테스트하기위한 스테이징 서버가 있어야합니다. 모든 개발 코드는 스테이징 서버에서 테스트되며 안정적이고 배치 준비가 완료된 경우에만 프로덕션 서버로 푸시됩니다. 그러나 개발자는 준비 서버에서 직접 작업하지 않습니다. 각 개발자는 수정 제어 및 소스 코드 관리 (SCM)를 사용하여 자신의 워크 스테이션에서 작업하여 팀의 다른 팀과 작업을 조정합니다.

SCM 시스템을 통해 팀 구성원은 서로 간섭하지 않고 코드의 서로 다른 분기 에서 병렬로 작업 할 수 있습니다. 테스트 목적으로 마스터 지점 만 스테이징 서버에 배치됩니다.

프로덕션, 스테이징 및 워크 스테이션간에 데이터베이스를 미러링하기 위해 공유 호스팅에 있고 자체 데이터베이스를 관리하지 않는 경우 사용할 수있는 백업 및 마이그레이션 이라는 모듈 이 있습니다. 자체 데이터베이스 서버를 관리하는 경우 해당 서버의 유일한 프로젝트이며 mysql 을 사용 하면 다음 명령 쌍이 편리합니다.

덤프하려면 :

mysqldump --all-databases --opt -u root -p > DUMP.sql

복원하려면

mysql -u root -p < DUMP.sql

귀하의 서버가 해당 서버의 유일한 데이터베이스 mysqldump가 아닌 경우 데이터베이스 만 덤프 하는 일부 버전 (또는 mysql을 사용하지 않는 경우 동등)을 스크립트 하십시오.

마스터 인 프로덕션 서버의 데이터베이스 인 정책을 작성하십시오. 스테이징 서버 및 워크 스테이션은 프로덕션 데이터베이스의 사본이어야하며 그 반대도 아닙니다.

Drupal 7은 모든 관리자 설정을 데이터베이스에 유지합니다. 즉, 프로덕션 사이트, 준비 사이트 및 워크 스테이션간에 데이터베이스를 미러링하면 기능 없이 admim 설정이 마이그레이션됩니다 .

이제 코드를 공유하십시오.

개발 팀 구성원간에 코드를 공유하는 표준 방법은 SCM 시스템을 사용하는 것입니다. Drupal은 기본적으로 git 이라는 시스템으로 관리됩니다 .

힘내 로컬 또는 원격 저장소를 사용할 수 있습니다. 팀 구성원이 동일한 실제 공간에있는 경우 스테이징 서버에서 로컬 저장소를 설정할 수 있습니다. 지리적으로 분산 된 경우 원격 리포지토리를 설정할 수 있습니다. 개발중인 코드에서 다른 사용자가 읽기 액세스 권한 을 갖지 않아도되는 경우 Drupal.org 의 샌드 박스 를 원격 저장소로 사용할 수 있습니다 . GitHub 에서 프로젝트 영역을 사용할 수도 있습니다 . GitHub 는 리포지토리 일뿐만 아니라 공동 작업을위한 몇 가지 도구와 함께 제공되며 공용 및 개인 리포지토리를 모두 허용합니다.

기본적으로 SCM 시스템을 사용하면 팀 구성원이 팀 구성원이 공유 한 저장소에서 소스 코드 및 문서를 가져 와서 작업 한 후 다시 밀어 넣을 수 있습니다. SCM은 변경 사항을 추적하고 충돌이있는 경우 (예 : 다른 팀 구성원이 변경 한 변경 사항이 포함되지 않은 코드를 푸시하려고 시도하는 경우)이 충돌을 해결하는 방법을 제안하고 제안합니다.

일반적으로 팀 구성원간에 작업을 나누는 방법에 대한 따뜻한 대화를 통해 갈등은 없습니다. 그러나 SCM 시스템이 사물을 추적하면 실수가 발생하거나 통신이 실패하더라도 충돌을 관리 할 수있게됩니다.

git (GIYF) 시작 및 사용에 대한 많은 자습서가 있습니다 . Scott Chacon 의 git-scm 웹 사이트와 Pro Git 을 추천합니다.