워드프레스 개발 및 도입 자동화

워드프레스 개발 및 도입 자동화

WordPress 프로젝트를 여러 개발자와 함께 작업한 적이 있습니까?분산형 개발팀과 자동 도입에 관한 베스트 프랙티스가 있습니까?

플러그인 개발자, 테마 개발자, 간단한 CSS 스타일 트위커를 포함한 다양한 수준의 개발자 팀이 몇 군데 다른 곳에 있으며, 다른 사람의 코드를 방해하지 않고 모든 사람이 각자 작업하고 지속적으로 변경을 전개할 수 있도록 좋은 시스템을 구축하고 싶습니다.

현재 시스템은 WordPress-MU 설치를 실행 중이며, 최종적으로 3.0으로 업그레이드될 예정입니다.이상적으로는 테마와 플러그인을 소스 컨트롤에 저장하고 핵심 WordPress 코드를 몇 가지 수정했기 때문에 저장소에도 저장해야 합니다.저장소를 구성하고 제어되지만 다소 자동화된 배포를 수행하는 최선의 방법을 찾는 데 어려움을 겪고 있습니다.

다양한 유형의 플러그인과 테마가 파일 시스템 또는 데이터베이스에 구성을 저장할 수 있는 경우 개발, 테스트, 스테이징 및 운영 환경에서 작업 및 도입 작업을 어떻게 처리합니까?정답은 "WordPress를 사용하지 마세요"일 수도 있다는 걸 알지만, 만약 사용해야 한다면, 어떻게 생각하시는지 알려주세요.

도와주셔서 고마워요.

데이브

지금까지 이 문제를 해결한 경위는 다음과 같습니다.

소스 코드 디렉터리:

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...

저는 Hudson CI Server(http://hudson-ci.org/)를 사용하여 서브버전 체크 아웃 태스크, ping, phpunit 등을 사용하여 자동 및 수동 빌드를 수행하고 있습니다.기본적으로 Hudson 서버는 전개하는 항목에 따라 서브버전으로부터 코드를 추출합니다.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-config.php)과 Apache 및 MySQL 구성 파일을 각 서버의 적절한 위치에 배포할 수도 있습니다.경우에 따라서는 여러 웹 서버 및 여러 데이터베이스 서버에 전개되며 빌드 설정의 대부분은 위에서 설명한 ping 빌드 파일과 .properties 파일을 통해 처리됩니다.

향후 개발 통합 환경이 구축되면 svn에서 코드를 체크인할 때 자동 도입이 이루어질 수 있습니다.

이 셋업에 의해, 조직내의 다른 스킬 세트(주로 CSS/HTML 대 PHP)를 가지는 다른 개발자가 개별적으로 작업해, 불필요한 인원을 다수 포함하지 않고 곧바로 적절한 환경에 코드를 변경할 수 있게 됩니다.Hudson은 제가 다양한 전개 작업을 잠글 수 있도록 해주었습니다.그러면 적절한 사람만이 작업을 구성하고 시작할 수 있습니다.

제가 설정한 내용에 대한 대략적인 개요입니다. 어떻게 생각하시는지 알려주세요.이 셋업의 가장 큰 문제는 키쌍, 사용자 계정, 파일 권한으로 모든 서버에서 rsync가 이루어졌다는 것입니다.

데이브

파일 시스템은 GIT를 사용하여 매우 잘 작동합니다.각 팀 구성원에 대한 지점을 가진 후 프로덕션 지점에 병합할 수 있습니다.문제가 발생하지 않도록 코드를 통합할 수 있습니다.

데이터베이스의 경우 Prod 데이터베이스를 계속 덤프하여 모든 사람과 공유합니다(GIT repo로 전송하면 모든 사람이 마지막으로 덤프를 갖게 됩니다).

나는 롤아웃이 꽤 유용하다는 것을 알았다.유료 서비스지만 시도해 볼 만합니다.스크립팅 없음 코딩 없음그냥 가입하고 조리법을 따라 하세요.이제 끝입니다.또, 도입전의 체크도 실시하기 때문에, 도입이 매우 원활하고 간단하게 됩니다.

언급URL : https://stackoverflow.com/questions/2895044/automating-wordpress-development-and-deployment