Dev, Stage и Production Развертывание для сайтов WordPress?


41

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

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


В pantheon.io есть dev, test и live для одного домена. Они используют git для файлов и передают базу данных между ними одним щелчком мыши. Вы можете попробовать бесплатно, и вы платите только тогда, когда вы «живете» - youtube.com/watch?v=KpGTDeqwgX4
jgraup

Ответы:


27

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

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

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

Структура мастер / разработчик настроена на частичную имитацию модели ветвления Винсента Дриссена . Я также использую его git-расширение git-flow и очень рекомендую это сделать.

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


Я собираюсь настроить установку wp аналогичным образом (но мы используем svn), и я хотел подтвердить ваш процесс обновления плагинов и wp: завершить обновление и проверить dev, зафиксировать изменения, развернуть их на стадии подготовки, проверить, в прямом эфире. Таким образом, вы никогда не устанавливали обновление wp на действующем сервере, в который вносили изменения через обновления в репозитории?
paullb

1
Как насчет изменений в БД, сделанных процедурой обновления. Как это влияет на производственную базу данных?
paullb

Этот рабочий процесс правильный @paullb, и вам не нужно беспокоиться об обновлениях БД. Как работает WordPress, обновления запускаются после обнаружения изменения, так что это работает точно так же, как работает ручное обновление (до ядра или плагина)!
Мэтью Бойнс

@MatthewBoynes, привет. Вы все еще используете этот worklow для своего развития? если так, я собираюсь применить этот рабочий процесс к моему проекту. спасибо :)
хакиоут

Я не знаю, но только потому, что это не применимо к проектам, над которыми я сейчас работаю, которые в основном размещены на VIP-сайте WordPress.com. Если бы это было применимо, я все равно использовал бы его (и фактически компания, в которой я ранее работал, продолжает использовать его).
Мэтью Бойнс

4

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

Учитывая это, вот что я использую:

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

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

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


Среда разработки очень хорошо подходит для тестирования ночных сборок, и git wordpress обновляется автоматически каждые 30 минут. Помимо децентрализации и лучшей работы для команд, я не знаю никого, кто перешел на git / hg, который вернулся к использованию SVN.
Wyck

1
Просто любопытно, почему вы не поставили весь каталог WP под контроль версий. Это кажется узким местом в рабочем процессе. Помещение WP в репозиторий дает всем разработчикам одинаковую кодовую базу и версию WP. Это также обеспечивает согласованность между средами. Смотрите ссылку Вика (на его ответ) на условные файлы wp-config.
Брайан Фегтер

2

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


2

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

Опция 1.

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

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

Варианты 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 )

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.