Wordpress 개발 및 배포 자동화

Question

WordPress 프로젝트에서 다른 위치의 여러 개발자와 함께 작업 한 적이 있습니까? 분산 개발 팀 및 자동화 된 배포와 관련된 모범 사례가 있습니까?

저는 플러그인 개발자, 테마 개발자 및 간단한 CSS 스타일 트위커를 비롯하여 다양한 위치에 여러 팀으로 구성된 팀이 있습니다. 모든 사람들이 작업 할 수있는 좋은 시스템을 설치하고 싶습니다. 다른 사람의 코드를 방해하지 않으면 서 변경 사항을 지속적으로 배포 할 수 있습니다.

시스템이 현재 WordPress-MU 설치를 실행하고 있으며 결국 3.0으로 업그레이드됩니다. 이상적으로, 우리는 소스 컨트롤에 테마와 플러그인을 저장하고 핵심 WordPress 코드를 약간 수정 했으므로 저장소로 이동해야합니다. 저장소를 구성하고 제어되지만 다소 자동화 된 배포를 수행하는 가장 좋은 방법을 알아내는 데 문제가 있습니다.

다른 유형의 플러그인과 테마가 파일 시스템이나 데이터베이스에 구성을 저장할 때 개발, 테스트, 스테이징 및 프로덕션 환경에서 작업하고 배포하는 것을 어떻게 처리합니까? 내가, 우리가 사용하는 파일 시스템에 대한 도움을

감사합니다,

데이브

Answer 1

는 지금까지이 문제를 해결 결국 어떻게

build/ - build files for phing and environment-specific properties files 
    build.xml 
    src_qa.properties - properties to use the qa server as the source for a deployment 
    dst_qa.properties - properties to use the qa server as the destination for a deployment 
    etc... for other environments 
conf/ - contains environment specific configuration files, each in a subfolder named after the environment 
    dev/ 
     db-config.php - config file for HyperDB - http://codex.wordpress.org/HyperDB 
     default - Apache conf that holds ServerAlias configs for multi-site WordPress 
     hosts - useful for developers to redirect their browser to various domains in different environments 
     htaccess.dist - for WPMU 
     httpd.conf - main Apache config file, specific to each environment 
     my.cnf - mysql config file 
     wp-config.php - main wordpress config file 
    qa 
     (same as dev/ but with different values in each file) 
    staging 
     (same as dev/ but with different values in each file) 
    prod 
     (same as dev/ but with different values in each file) 
src/ - wordpress source code 
    wp-admin/ 
    wp-content/ 
     mu-plugins/ 
     plugins/ 
     themes/ 
    wp-includes/ 
test/ - holds WP test suite and custom tests for plugins, themes, etc... 

나는에 허드슨 CI 서버 (http://hudson-ci.org/)를 사용하고 자동 및 수동 Subversion을 체크 아웃 작업을 사용하여 구축 , phing, phpunit, etc ... 기본적으로 Hudson 서버는 배포하려는 대상에 따라 Subversion에서 코드를 가져 오며, rsync는 CI 서버에서 대상 서버로 배포 할 파일입니다.

또는 프로덕션에서 직접 프로덕션으로의 스테이징에서 Hudson rsync는 파일을 준비에서 CI 서버로 보낸 다음 프로덕션으로 백업합니다.

core WP code - deploys core WP files and mu-plugins from src to dst 
    svn to qa 
    svn to staging 
    staging to prod 
WP plugins/ folder - deploys only the plugins folder 
    svn to qa 
    svn to staging 
    staging to prod 
WP themes/ folder - deploys the entire themes folder 
    svn to qa 
    svn to staging 
    svn to prod 
Specific themes - deploys a specific theme (chosen through a drop down during the build process using Hudson's parameterized build feature - http://wiki.hudson-ci.org/display/HUDSON/Parameterized+Build) 
    svn to qa 
    svn to staging 
    svn to prod 

허드슨 작업도 환경 특정 PHP 파일을 배포 할 수있는 능력을 가지고있다 (예 : WP-config.php를, DB-설정을 :

나는 다음과 같은 기능 조각이 허드슨에서 작업 설정을 만들 수 있습니다. php), Apache 및 MySQL 설정 파일을 각 서버의 적절한 위치에 저장합니다. 경우에 따라 여러 웹 서버와 여러 데이터베이스 서버에 배포하고 대부분의 빌드 구성은 위에서 언급 한 phing 빌드 파일과 .properties 파일을 통해 처리됩니다.

향후 개발 통합 환경이 마련되면 모든 코드의 svn checkin시 자동 배포가 수행 될 것입니다.

이 설정을 사용하면 다른 스킬 셋 (CSS/HTML 대 PHP)을 사용하는 조직의 여러 개발자가 별도로 작업하여 불필요한 사람들이 많이 참여하지 않아도 코드를 적절한 환경으로 신속하게 변경할 수 있습니다. Hudson을 사용하면 다른 배포 작업을 잠글 수 있으므로 적절한 사람 만 구성하여 액세스 할 수 있습니다.

그건 내가 설정 한 것에 대한 수준 높은 개요입니다. 당신의 생각을 알려주세요. 이 설정에서 가장 큰 어려움은 모든 다른 서버에서 rsync를 사용하여 키 쌍, 사용자 계정 및 파일 사용 권한이었습니다.

데이브

Answer 2

을 "워드 프레스를 사용하지 마십시오"대답은있을 수 있습니다 실현하지만, 나를 어떻게 생각하는지 알려 있다고 가정 GIT는 매우 잘 작동합니다. 각 팀 구성원에 대해 지사를 만든 다음 프로덕션 지점으로 병합 할 수 있습니다. 우리는 코드를 아무 문제없이 통합 할 수 있습니다.

데이터베이스의 경우 계속 데이터베이스를 덤프하고 모두와 공유합니다 (GIT 저장소로 보내면 모든 사람이 최신 덤프를 갖게됩니다).

소스 코드 디렉토리 : 여기