Задний план

Я близок к завершающей стадии создания моего первого довольно большого сайта WordPress, и теперь я сталкиваюсь с некоторыми трениями. По большей части сайт разрабатывался на моей локальной машине, и я отправлял изменения на промежуточный сервер для проверки ( см. Этот вопрос для получения дополнительной информации ). Решение, которое я выбрал, работало довольно хорошо, когда я редактировал контент, но теперь некоторые другие редактируют контент, пока у меня все еще есть возможности для добавления. Идея заключалась в том, что мы могли бы сделать вещи быстрее, если бы функции и контент объединились вместе ... но теперь я не уверен.

В настоящее время содержимое в базе данных на промежуточном сервере отличается от содержимого на моем локальном компьютере. Это само по себе прекрасно, так как мне не нужна окончательная копия тела на моей локальной машине, но мне нужно больше заниматься разработкой, которая повлияет на базу данных (установите / напишите еще пару плагинов, которым нужны свои собственные таблицы).

Мой вопрос:

Есть ли простой способ автоматизировать объединение баз данных, чтобы несколько человек могли работать над установкой WordPress? Конечно, я мог бы просто экспортировать таблицы, которые, как я знаю , изменились на моем локальном компьютере, и перенести их на промежуточный сервер, но возможно, что на промежуточном сервере есть вещи, которые я хотел бы отключить. Я мог бы получить выходные данные SQL обеих БД и различить их ... но это кажется утомительным и хакерским. Мне интересно, если это проблема, которую решили другие; если есть общепринятый способ справиться с подобными вещами.

Благодарность!

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

Все в Git

Это было то, чем я занимался, даже когда задавал вопрос, но это хорошо, чтобы подчеркнуть это. Использование Git не только помогло нам стать более продуктивным, но и несколько раз спасло наши коллективные задницы.

Вам когда-нибудь приходилось делать серьезные структурные обновления сайта, получать одобрения на эти обновления от клиента и все время вносить незначительные обновления в не обновленную версию? У нас есть, и Git позволяет нам делать это. Описание этой настройки будет немного запутанным, но в основном мы создали новую ветвь, перетащили эту ветвь на сервер и подключили субдомен к этой ветке.

Мы также были спасены Git. Это, конечно, позволяет нам откатывать изменения, что замечательно, но также позволяет возвращать старые версии файлов. Это означает, что, если клиент спрашивает: «Помните, как эта часть сайта работала около года назад? тому назад.

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

Используйте Git для развертывания

Мы делаем наш хостинг WordPress на Media Temple , и они нам действительно нравятся. Они не самый дешевый поставщик, но их обслуживание превосходно, а их серверы действительно хорошо настроены. Также предоставляет Git по умолчанию. Это означает, что мы можем настроить сервер как репозиторий Git и извлекать изменения таким образом, вместо использования SFTP. Это также означает, что выполнение работы на сервере не грозит перезаписью (поскольку эти изменения можно просто объединить и перенести обратно).

Поскольку мы используем BitBucket в качестве нашего хоста Git, здесь требуется дополнительная работа. Прежде всего, мы используем файлы .ssh / config, чтобы мы могли вводить такие вещи, как ssh sitenameвход на наши серверы (мы также используем SSH без пароля , что делает это очень простым). Мы также всегда используем ssh парольные фразы (Mac OS X делает это очень просто, позволяя хранить вашу парольную фразу в Keychain.app ). Наконец, мы добавляем строку ForwardAgent к записи .ssh / config на хостах, с которых мы хотим получить. Это означает, что нам нужен только открытый ключ SSH каждого человека в BitBucket, а не открытый ключ каждого сервера. Мы также должны держать .gitкаталог на один каталог выше общедоступного каталога HTML.

Автоматизированные дампы базы данных

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

У каждого свой wp-config

Поскольку у всех нас есть свои собственные имена пользователей и пароли в локальной базе данных, и поскольку мы можем использовать разные имена и механизмы обслуживания, у каждого из нас есть свой собственный файл wp-config. Каждый из них хранится в Git с именем вроде wp-config-gavin.php, и когда мы хотим использовать этот конфиг, мы ставим его на символическую ссылкуwp-config.php (которая игнорируется Git при использовании .gitignore ).

Это также позволяет нам переопределить siteurlпараметр в wp_optionsтаблице базы данных следующим образом:

define('WP_SITEURL', 'http://sitename.localhost');
define('WP_HOME', 'http://sitename.localhost');

Это препятствует тому, чтобы WordPress просматривал базу данных для определения местоположения сервера, и означает, что нет никаких странных различий в расположении между локальной и серверной установками.

Последнее замечание о файлах wp-config.php: убедитесь, что они хранятся над общедоступным каталогом HTML и разрешите чтение только для веб-пользователя . Это имеет огромное значение для защиты WordPress.

Проблема с базой данных

Наконец, суть вопроса.

Что я должен был принять, так это то, что при использовании WordPress нет хорошего способа «объединить» изменения базы данных. Вместо этого нам нужно было разработать правила поведения, чтобы решить эту проблему. Правила довольно просты, и до сих пор хорошо нам служили.

Во время разработки есть один человек, который "владеет" сайтом. Этот человек обычно выполняет настройку (собирает пакет хостинга, запускает проект Basecamp, разрезает дизайн и тому подобное). Как только этот человек достигнет разумного уровня, выгрузите базу данных для установки WordPress и поместите ее в Git. С этого момента каждый, кто занимается разработкой, использует этот дамп базы данных, и владелец является единственным, кто вносит изменения в базу данных.

Как только сборка сайта идет немного дальше, сайт помещается на сервер. С этого момента база данных сервера является канонической. Каждый (включая владельца) должен внести все изменения в базу данных на сервере и вытащить изменения для локальной разработки и тестирования.

Этот процесс не идеален. Все еще возможно, что кому-то может понадобиться вносить изменения в бэкэнд WordPress локально во время разработки, а затем снова вносить эти изменения в производство. Тем не менее, мы обнаружили, что такие вещи встречаются редко, и этот процесс работает довольно хорошо для нас.

Я работаю над такой установкой и уже отвечал на подобные вопросы раньше . Ниже приведены мои предпочтительные настройки для такого рода работы. Поскольку вы хотите объединить базы данных вместо замены существующей базы данных, я бы добавил к ним предостережение, чтобы не использовать флаг --add-drop-table при выполнении дампа MySQL.

• Шаг 1. Mysqldump ваша база данных разработки
• Шаг 2. Замените все экземпляры development.domain.com на production.domain.com ^^
• Шаг 3. Войдите в MySQL, запустите команду SOURCE для импорта данных, например source /path/to/file

^^ Как заменить все экземпляры старого домена новым: (1) Скопируйте скрипт ниже. (2) chmod +xэто. (3) Запустите его.

Использование: ./script.sh development-dump.sql > production-dump.sql

#!/bin/sed -f
s/'\([^\\']*\)development.domain.com\([^\\']*\)'/'\1production.domain.com\2'/g

Я экспериментирую с различными решениями этой же проблемы прямо сейчас. Это определенно хитрый.

Мое текущее решение - сделать локальный дамп mysql, используя флаг --skip-extended-insert. Я полагаю, что этот флаг заставляет оператор вставки записи генерироваться для каждой строки базы данных, делая дамп более дружественным к слиянию. Я взял этот трюк из этой статьи: http://www.viget.com/extend/backup-your-database-in-git/ .

Затем я контролирую исходный файл результирующего дампа .sql, используя Git вместе с исходными файлами сайта. Когда другой разработчик вносит изменения в код, вместе с ним появляется файл .sql. Затем он импортирует этот файл в свою локальную версию базы данных. Мы оба настроили наши соответствующие локальные базы данных одинаково на обеих машинах, используя MAMP, поэтому нет необходимости выполнять поиск и замену.

Были проблемы слияния, поэтому мы пытаемся применить подход «по очереди» ко всему, что приведет к изменению базы данных. Прежде чем я сделаю в Wordpress что-нибудь, что изменит базу данных, я проверяю, что он проверил свой последний дамп, вытащил его и импортировал, а затем попросил его не вносить никаких изменений в БД, пока я не внесу и не проверил в своей. Это, очевидно, не идеально, и я ищу лучшее решение, но это начало. Это также дает нам контроль версий БД, что приятно.

Я могу закончить тем, что настроил нас на сервере совместно используемую базу данных разработчиков и попробую подключить обе наши локальные копии сайта к одной и той же БД через туннелирование SSH. Этот подход, однако, будет сталкиваться с проблемами всякий раз, когда один из нас устанавливает плагин. В основном файлы PHP и БД MySQL будут не синхронизированы.

Я хочу услышать, как другие справляются с этой проблемой.