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

Question

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

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

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

Как вы справляетесь с работой и развертыванием в средах разработки, тестирования, подготовки и производства, когда различные типы плагинов и тем могут хранить конфигурации в файловой системе или в базе данных? Я понимаю, что ответом может быть "Не используйте 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...

Я использую сервер Hudson CI ( http://hudson-ci.org/) для автоматизированных и ручных сборок с использованием задач извлечения Subversion, phing, phpunit и т. Д. По сути, сервер Hudson извлекает код из Subversion в зависимости от того, что вы хотите развернуть, и он 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's 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) работать отдельно и быстро вносить изменения в свой код в нужную среду без привлечения ненужных людей. Хадсон позволяет мне блокировать различные задания по развертыванию, так что только нужные люди имеют доступ к их настройке и запуску.

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

Дейв

Answer 2

Для файловой системы мы используем GIT, и она работает очень хорошо. Вы можете ч

Answer 3

Я обнаружил, что выкатывание было весьма полезным. Это платная услуга, но стоит попробовать. Нет сценариев Нет кода вообще. Просто зарегистрируйтесь и следуйте рецепту. Вы сделали. Кроме того, он выполняет предварительные проверки развертывания, что делает развертывание довольно гладким и простым.