Автоматизация разработки Wordpress и развертывания
Кто-либо когда-либо работал над проектом WordPress с несколькими разработчиками в различных местоположениях? Есть ли лучшие практики вокруг распределенных групп разработчиков и автоматизированных развертываний?
У меня есть команда различных степеней разработчиков, включая сменных разработчиков, разработчиков темы, и простой CSS разрабатывает tweakers в нескольких различных местоположениях, и я хотел бы установить хорошую систему для всех, чтобы смочь работать над их отдельными частями и непрерывно развертывать изменения, не нарушая ничей больше код.
Система выполняет установку WordPress-MU в данный момент, и она будет в конечном счете обновлена до 3,0. Идеально, мы сохранили бы темы и плагины в управлении исходным кодом, и так как несколько модификаций были сделаны к базовому коду WordPress, оно должно войти в репозиторий также. Я испытываю затруднения при выяснении лучшего способа структурировать репозиторий и сделать управляемые но несколько автоматизированные развертывания.
Как Вы обрабатываете работу в и развертывание на разработке, тестировании, подготовке и продуктивных средах, когда различные типы плагинов и тем могут сохранить конфигурации в файловой системе или в базе данных? Я понимаю, что ответ может быть, "Не используют WordPress", но предположение, что я имею к, сообщаю мне то, что Вы думаете,
Спасибо за помощь,
Dave
2 ответа
Вот как я решил эту проблему:
Каталоги исходного кода:
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 извлекает код из subversion в зависимости от того, что вы хотите развернуть, и он rsync'ит файлы для развертывания с сервера CI на целевой сервер.
Или, в случае развертывания из staging непосредственно в production, Hudson rsync'ит файлы из staging, вниз на CI-сервер, а затем обратно в production.
В 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 checkin любого кода.
Такая настройка позволяет различным разработчикам в организации с разными навыками (CSS/HTML против PHP в основном) работать отдельно и быстро доставлять свои изменения кода в соответствующие среды без привлечения кучи лишних людей. Hudson позволяет мне блокировать различные задания по развертыванию, чтобы только нужные люди имели доступ к их настройке и запуску.
Это своего рода обзор того, что я установил, дайте мне знать, что вы думаете. Наибольшее раздражение при такой настройке вызывали пары ключей, учетные записи пользователей и разрешения на файлы при использовании rsync на всех различных серверах.
Dave
Для файловой системы мы используем GIT, и он работает очень хорошо. Вы можете создать ветку для каждого члена команды, а затем объединить ее с производственной веткой. Мы можем сохранить интегрированный код без каких-либо проблем.
Что касается базы данных, я продолжаю выгружать базу данных prod и делиться ею со всеми (вы даже можете отправить ее в репозиторий GIT, и тогда у всех будет самый последний дамп).