Развертывание WordPress на dev, stage и production серверах

У меня есть настройка, которой я очень горжусь, и она отлично работает для моей команды.

Общая структура

Я храню всю установку под git. Все изменения, будь то обновление системы, добавление/обновление плагина, добавление/обновление темы, проходят через один и тот же рабочий процесс. Изменения можно откатить в любой момент. У меня есть сервер развертывания (старый настольный компьютер P4), на котором работает gitosis, но вы также можете использовать github или gitolite. В git у меня есть две "особые" ветки: master и develop (подробнее объяснено ниже). Мои продакшен- и стейджинг-серверы работают в облаке.

Среды разработки

Каждый разработчик запускает свой собственный сервер разработки на своем компьютере. Что касается баз данных, необходимость в реальных данных возникает крайне редко. Мы в основном используем тестовые данные для тестирования тем. В остальных случаях экспорт и импорт покрывают большинство потребностей. Если работа с БД критична, вы можете настроить репликацию или организовать синхронизацию по запросу. Когда я впервые настраивал эту структуру, я думал, что это будет критично, поэтому начал писать набор инструментов для этого, но, к моему удивлению, они действительно не понадобились. (примечание: так как они не были необходимы, я не стал их дорабатывать, поэтому в них есть баги, например, они заменяют домен в сериализованных данных).

Стейджинг-среда

Когда коммиты отправляются из ветки develop в gitosis, они автоматически развертываются на нашем стейджинг-сервере. База данных стейджинга является слейвом для продакшен-базы данных.

Продакшен-среда

Когда коммиты отправляются в gitosis в ветку master, они автоматически развертываются на продакшен-сервере.

Проблема с wp-config.php

Нужно, чтобы wp-config.php был уникальным для каждого сервера, но при этом оставался под контролем версий. Мое решение — использовать .gitignore для игнорирования wp-config.php и хранить версии для стейджинга и продакшена под разными именами. Затем на каждом сервере я создаю симлинк, например wp-config.php -> wp-config-production.php. Каждый пользователь хранит свою БД со своими учетными данными и своими (неотслеживаемыми) настройками в wp-config.php.

Другие заметки

Я использую Rackspace Cloud, что просто замечательно и недорого. С ним я могу держать стейджинг- и продакшен-серверы идентичными. Сейчас я также пишу плагины, использующие их API, что позволяет мне управлять сервисами прямо из WordPress — это прекрасно.

Каталоги кеша, загружаемых файлов и т. д. добавлены в .gitignore. При желании можно настроить cron-задачу для периодического сохранения загрузок и отправки их в gitosis, но мне это никогда не казалось необходимым.

Структура master/develop частично повторяет модель ветвления Vincent Driessen. Я также использую его расширение git — git-flow, и я очень рекомендую его.

У меня уже больше года работает около 10 разработчиков с этой структурой, и это просто мечта. Надежная, безопасная, быстрая, функциональная и гибкая — большего и не нужно!

Во-первых, важно подумать что именно вы собираетесь контролировать с помощью системы управления версиями. Я бы рекомендовал не помещать всю директорию WordPress под контроль версий. Наиболее логичным представляется добавление в систему управления версиями папки wp-content/themes/YourThemeName. Для крупного сайта со множеством сложных плагинов можно рассмотреть включение в систему управления версиями и папки wp-content/plugins. Если уж совсем необходимо, можно включить и wp-content/uploads. Ответы ниже будут немного отличаться в зависимости от того, что именно вы контролируете.

Исходя из этого, вот что я использую:

Локальная среда: Настройте LAMP-стек на своем компьютере. Используйте тот же URL, что и на сайте разработки. Применяйте VirtualHosts и записи в файле .hosts для имитации среды разработки с точки зрения URL. Если вы контролируете только тему, подумайте об использовании SSHFS для связи с wp-content/plugins и wp-content/uploads. Подумайте об использовании базы данных с вашей установки для разработки, если только вы не занимаетесь действительно сложной работой.

Среда разработки: Проверьте рабочую копию вашего репозитория в среде WordPress. Настройте POST-COMMIT-хук в SVN для обновления этого репозитория после каждого коммита. Это позволит поддерживать его в актуальном состоянии. (Можно считать это упрощенной формой непрерывной интеграции.)

Продакшн-среда: Используйте именованный тег версии, представляющий финальный кандидат. Когда потребуется использовать новую версию, переключите тег и обновите репозиторий.

Недавно мы обнаружили RAMP. Примечание: это лишь часть всего процесса, но синхронизация баз данных контента между серверами, вероятно, является самой сложной частью.

Я делаю это с помощью git и mercurial, главное убедиться, что вы используете приватный репозиторий.

Вариант 1.

Единственная проблема — это файл config.php, который можно настроить так, чтобы git игнорировал его при пуше или перед инициализацией.

Используйте .gitignore или git update-index --assume-unchanged config.php (перед использованием команды assume-unchanged лучше почитать о ней подробнее)

Вариант 2.

Добавьте условие в config.php, которое проверяет URL и применяет нужные учетные данные, например: "если URL сервера = dev, используй учетные данные A, иначе — учетные данные B" и т. д.

Марк объясняет это лучше: http://markjaquith.wordpress.com/2011/06/24/wordpress-local-dev-tips/

P.S. Также можно раздавать файлы напрямую из удаленного репозитория вместо традиционного "файлового сервера". (Очень скучное видео, которое я записал на эту тему: http://www.youtube.com/watch?v=8ZEiFi4thDI)