Автоматизация разработки и развертывания Wordpress

Кто-нибудь когда-либо работал над проектом WordPress с несколькими разработчиками в разных местах? Существуют ли лучшие практики вокруг распределенных групп разработчиков и автоматизированных развертываний?

У меня есть команда разной степени разработчиков, включая разработчиков плагинов, разработчиков тем и простых твикеров в стиле CSS, в нескольких разных местах, и я хотел бы настроить хорошую систему, чтобы каждый мог работать над отдельные части и постоянно разворачивать изменения, не нарушая код другого пользователя.

В настоящее время система запускает WordPress-MU, и в конечном итоге она будет обновлена до 3.0. В идеале мы бы сохранили темы и плагины в исходном управлении, и, поскольку в основной код WordPress внесены некоторые изменения, он также должен войти в репозиторий. У меня возникли проблемы с поиском наилучшего способа структурирования репозитория и управления, но несколько автоматизированного развертывания.

Как вы обрабатываете работу и развертывание для разработки, тестирования, промежуточной и производственной среды, когда различные типы плагинов и тем могут хранить конфигурации в файловой системе или в базе данных? Я понимаю, что ответ может быть "Не используйте WordPress", но, полагая, что я должен, дайте мне знать, что вы думаете,

Спасибо за вашу помощь,

Dave

Ответ 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...

Я использую Hudson CI Server (http://hudson-ci.org/) для автоматической и ручной сборки, используя задачи проверки subversion, phing и phpunit и т.д.... В основном, сервер Hudson извлекает код из подрывной деятельности в зависимости от того, что вы хотите развернуть, и он rsync файлы, которые будут развернуты с сервера CI, на целевой сервер.

Или, в случае развертывания от стадии постановки непосредственно на производство, Hudson rsync файлы от этапа, вплоть до CI-сервера, а затем обратно в производство.

У меня есть настройка заданий сборки в hudson для следующих функциональных возможностей:

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 parameterized build feature - http://wiki.hudson-ci.org/display/HUDSON/Parameterized+Build)
    svn to qa
    svn to staging
    svn to prod

Работы hudson также имеют возможность развернуть файлы PHP (например, wp-config.php, db-config.php), специфичные для среды, а также файлы конфигурации Apache и MySQL в соответствующие места на каждом сервере. В некоторых случаях мы развертываем на несколько веб-серверов и несколько серверов баз данных, а большая часть конфигурации сборки берется за файл сборки phing и файлы .properties, упомянутые выше.

В будущем, когда у нас есть среда интеграции разработки, мы, вероятно, сделаем автоматическое развертывание при проверке svn любого кода.

Эта настройка позволяет различным разработчикам в организации с различными наборами навыков (главным образом, CSS/HTML и PHP) работать отдельно и быстро менять свои кодовые изменения в соответствующие среды без привлечения нескольких ненужных людей. Хадсон позволяет мне блокировать различные задания развертывания, поэтому только нужные люди имеют доступ к их настройке и отключают.

Этот вид высокого уровня того, что я настроил, дайте мне знать, что вы думаете. Самыми большими неприятностями в этой настройке были keypairs, учетные записи пользователей и разрешения файлов с rsync на всех разных серверах.

Dave

Ответ 2

Для файловой системы мы используем GIT, и она работает очень хорошо. У вас может быть филиал для каждого члена команды, а затем объединить его в производственную ветвь. Мы можем сохранить наш код интегрированным без каких-либо проблем.

Для базы данных я все время сбрасываю базу данных prod и обмениваюсь со всеми (вы даже можете отправить ее в репозиторий GIT, а затем у всех будет самая последняя дамп).