gavinanderegg
  • 0
Учитель

Несколько разработчиков/редакторов работают над сайтом в процессе

  • 0

Задний план

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

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

Мой вопрос:

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

Спасибо!

Share
  1. Голосование за закрытие или переход на другой сайт (Ян: есть мысли по поводу хорошего сайта? Возможно, суперпользователь). Это не специфично для WordPress, так как вы столкнетесь с теми же проблемами на Drupal, Joomla или любом другом сайте, управляемом PHP + MySQL, если уж на то пошло.

    • 0
    • При этом я предлагаю вам использовать удаленный промежуточный сервер вместо локального.

      • 0
    • @John P Bloch: С Drupal в этой ситуации очень поможет что-то вроде Drush. Я лично привык к Django, где такого рода проблемы смягчаются фикстурами. Кроме того, в настоящее время у меня есть два промежуточных сервера: один локальный и один удаленный. Дело в том, что я выполняю свою работу на своем удаленном компьютере, но мне нужно отправить ее на сервер, чтобы другие могли ее увидеть. Конечный сервер — это то, что будет настроено, когда мы соберем все вместе.

      • 0
    • @John P Bloch — я думаю, что есть причины, по которым это имеет смысл здесь как хороший вопрос. У меня нет времени, чтобы ответить на него в данный момент, но, надеюсь, у других есть.

      • 0
    • @Gavin: Извините, я неправильно истолковал ваш вопрос. Да, я считаю, что это перезапишет все на рабочем сервере. :/

      • 0
    • будьте осторожны: sed не может работать с данными, закодированными в дампах mysql, которые ранее были сериализованы.

      • 0
    • вопрос, на который вы ответили ранее, на самом деле был моим 🙂 Однако я чувствую, что задаю здесь другой вопрос. Замечательно сбрасывать всю БД, когда над ней работаю только я, но если я сделаю это в описанной выше ситуации, то либо перезапишу чужие изменения, либо перезапишу свои собственные изменения. Я хочу объединить изменения, поскольку над экземплярами WordPress работает несколько человек.

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

    Все в гите

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

    • 0
  3. Я работаю над такой установкой и уже отвечал на такие вопросы. Ниже приведены мои предпочтительные настройки для такого рода работы. Поскольку вы хотите объединить базы данных вместо замены существующей базы данных, я бы добавил к ним предостережение не использовать флаг —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
    
    • 0
  4. Я сейчас экспериментирую с разными решениями этой же проблемы. Это определенно сложно.

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

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

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

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

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

    • 0

Оставить ответ

You must login to add an answer.