Разработка, тестирование и развертывание для сайтов на WordPress.

Мне нужно иметь возможность выполнять итерации dev/stage/production (на отдельных серверах) для сайта на WordPress. Обычно я использую git, но это явно не сработает с сайтами на WordPress из-за зависимости от базы данных для главной конфигурации… ну, почти всего.

Поэтому мой вопрос: как вы это делаете? Я быстро погуглил и увидел несколько плагинов, это единственный способ? Какие из них работают лучше всего по критериям простоты использования, скорости, надежности и интерфейса?

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

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

Я держу всю установку под контролем версий (git). Все изменения, будь то обновление системы, добавление/обновление плагина или темы, проходят через один и тот же рабочий процесс. Изменения могут быть отменены за считанные минуты. У меня есть сервер развертывания (старый настольный П4), на котором работает 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 настроена так, чтобы частично имитировать модель ветвления Винсента Дриессена. Я также использую его git-расширение git-flow, и я бы также очень рекомендовал это.

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

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

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

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

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

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

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

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

Вариант 1.

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

Используйте .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/

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

Для эффективного управления средами разработки, тестирования и производства для сайтов на WordPress многие разработчики используют системы контроля версий, такие как Git или SVN. Обычно подход заключается в том, чтобы держать установку WordPress под контролем версий, сосредотачиваясь на директории wp-content, которая включает темы и плагины. Это позволяет обеспечивать последовательные обновления через среды и помогает определить, находится ли сайт в производственной или разработческой среде. Для развертывания изменения отправляются через определенные ветки, где сервера тестирования и продакшен отражают последние обновления, сохраняя при этом уникальные конфигурации (например, wp-config.php) для каждой среды. Инструменты, такие как Pantheon, могут упростить этот процесс, предлагая встроенные среды тестирования и возможности синхронизации баз данных.