꽤 자랑스러워하는 설정이 있으며 팀에 매우 적합합니다.
일반 구조
전체 설치를 자식으로 유지합니다. 시스템 업데이트, 플러그인 추가 / 업데이트, 테마 추가 / 업데이트 등 모든 변경 사항은 동일한 워크 플로를 거칩니다. 변경 사항은 즉시 통지 할 수 있습니다. gitosis를 실행하는 배포 서버 (이전 P4 데스크톱)가 있지만 github 또는 gitolite 를 쉽게 사용할 수 있습니다 . 자식에는 두 개의 "특별한"지점이 master있으며 develop(아래에 더 자세히 설명되어 있습니다). 내 프로덕션 및 준비 서버는 클라우드 기반입니다.
개발 환경
모든 개발자는 자신의 컴퓨터에서 자체 개발 서버를 실행합니다. 데이터베이스 측면에서 라이브 데이터가 필요한 것은 거의 문제가되지 않았습니다. 우리는 주로 테마 단위 테스트 데이터를 사용합니다 . 그렇지 않으면 내보내기 및 가져 오기가 대부분을 포함합니다. DB 조각이 중요한 경우 주문형 동기화를 위해 복제를 설정하거나 무언가를 설정할 수 있습니다. 처음 에이 구조를 설정할 때 이것이 중요 할 것이라고 생각했기 때문에이 도구 를 작성하기 시작 했지만 놀랍게도 실제로 필요하지 않았습니다. (참고 : 필요하지 않았으므로 연마하지 않았으므로 직렬화 된 데이터에서 도메인을 대체하는 버그가 있습니다).
준비 환경
커밋이 develop브랜치에서 gitosis 로 푸시되면 스테이징 서버에 자동으로 배포됩니다. 준비 데이터베이스는 프로덕션 데이터베이스의 슬레이브입니다.
생산 환경
커밋이 master브랜치에서 gitosis로 푸시되면 프로덕션 서버에 자동으로 배포됩니다.
wp-config.php 문제
당신이 원하는 wp-config.php서버로 서버에서 고유해야합니다,하지만 당신은 또한 버전 통제를 유지하려는. 내 솔루션은을 .gitignore무시 wp-config.php하고 준비 및 프로덕션 버전을 다른 이름의 파일로 저장하는 데 사용 되었습니다 . 그런 다음 각 서버에서 symlink eg wp-config.php -> wp-config-production.php. 그런 다음 각 사용자는 자체 (트랙되지 않은) wp-config.php 설정으로 자체 자격 증명을 사용하여 자체 DB를 유지합니다.
기타 사항
나는 경이롭고 저렴한 Rackspace Cloud를 사용 합니다. 이를 통해 스테이징 서버와 프로덕션 서버를 동일하게 유지할 수 있습니다. 또한 현재 API를 사용하여 WordPress 내에서 바로 서비스를 제어 할 수있는 플러그인을 작성하고 있습니다.
캐시 디렉토리, 파일 업로드 디렉토리 등이 모두 .gitignore에 추가됩니다. 원한다면 정기적으로 업로드를 체크인하고 gitosis로 푸시하도록 cron 작업을 설정할 수는 있지만 결코 필요하지 않은 것 같습니다.
마스터 / 개발 구조는 Vincent Driessen의 브랜칭 모델 을 부분적으로 모방하도록 설정되었습니다 . 나는 또한 그의 git extension git-flow를 사용 하고 그것을 강력히 제안한다.
나는 10 년 정도의 개발자 가이 구조를 1 년 넘게 일해 왔으며 함께 일하는 것은 꿈이었습니다. 신뢰할 수 있고 안전하며 빠르며 기능적이며 민첩하므로 더 많은 것을 요구할 수 없습니다!