Рабочий процесс WordPress и Git

23

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

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

- Управление версиями WordPress

- Управление развертыванием тем WordPress с помощью Git

- Управляйте своей собственной темой WordPress, используя git вместо FTP

В настоящее время мой рабочий процесс выглядит следующим образом.

  • Установите WordPress локально
  • Разработать тему
  • Экспорт баз данных WordPress с локального сервера
  • Импорт базы данных WordPress на удаленный сервер
  • Загрузить файлы WordPress и тему через FTP
  • Клиент вносит изменения
  • Загрузите файлы и темы WordPress через FTP и экспортируйте базы данных WordPress с удаленного сервера
  • Заменить файлы локально
  • Внести изменения в развитие
  • Повторная загрузка через FTP, экспорт и импорт базы данных на удаленный сервер

Я понимаю, что Git может упростить этот процесс. Кажется, лучший способ сделать это - иметь файл .gitignore, который игнорирует определенные каталоги, которые не нужно отслеживать, а также иметь как локальный, так и удаленный файл wp-config.php.

Но как вы справляетесь с базами данных? Клиенты обычно вносят изменения (посты / страницы / плагины). Нужно ли мне экспортировать данные из удаленной базы данных и импортировать обратно на мой локальный сервер?

Может кто-нибудь предложить лучший рабочий процесс для меня здесь? И проведи меня по ступенькам.

Кроме того, я бы хотел использовать Bitbucket, поскольку частные репозитории с ними бесплатны, в отличие от GitHub.

Любая помощь будет оценена.

Заранее спасибо!

deployment git realph
источник
Как прошло? Вы поняли это? Имея такие же проблемы здесь.
qwerty
3
Не могли бы вы немного сфокусировать свой вопрос? Вы спрашиваете о git, но затем переходите к базам данных, а git не является инструментом для решения этих проблем.
Rarst
4
Я думаю, что ваш вопрос действителен. У меня такой же рабочий процесс, и, общаясь с другими разработчиками, заметил, что они также имеют такой же рабочий процесс. Но это действительно отнимает много времени и открывает много возможностей для ошибок. Я также был бы заинтересован в лучшем решении.
Гданиэль

Ответы:

6

Я являюсь одним из разработчиков WP Migrate DB Pro и хотел бы ответить на вопрос @ Ennui:

«Знаете ли вы, учитывает ли сценарий db url replace, который он запускает, сериализованные строки?»

Да, он обрабатывает сериализованные данные. Фактически, это основная причина, по которой я разработал бесплатную версию плагина еще в 2009 году. :)

К сожалению, у меня всего 41 репутация, поэтому я не смог ответить на комментарий @ Ennui. Простите за это.

Bradt
источник
1
Получил 50 сейчас :) Отличный плагин человек.
Андрей Бартель
4

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

Это не то, на что похож мой рабочий процесс, и это отличает мой подход (и ответ) от большинства остальных ответов.

  1. Установите WordPress локально
    1. Это клонировано из локального репозитория Git, содержащего последнюю стабильную версию.
    2. Я также храню локальную копию последнего выпуска нескольких плагинов, которые я почти всегда устанавливаю.
  2. Создайте тему и все необходимые плагины
  3. Загрузить на публичный промежуточный сервер
    1. Клиенту предоставлен доступ, но он не может изменить код, и он сказал, что изменения базы данных не будут перенесены на рабочий сайт.
    2. Это означает, что нет причин загружать код обратно на сервер разработки.
    3. И нет причин для повторной синхронизации локальной базы данных
  4. Внесите изменения в локальный сайт на основе наших сотрудников и отзывов клиентов.
  5. Загрузить изменения
  6. Повторите по мере необходимости (но с увеличением сопротивления :))
  7. Если мы предоставляем контент, что не всегда так, мы (не клиент) будем очищать базу данных на промежуточном сервере и загружать контент.
  8. Разверните, загрузив локальный код на рабочий сайт.
  9. Если мы создали контент, контент экспортируется с промежуточного сайта через инструмент экспорта vanilla и импортируется на рабочий сайт.
    1. Это единственный раз, когда мне нужно переместить базу данных, и это делается довольно стандартными инструментами. Я буду использовать Velvet Blues Update URLs для очистки базы данных, если это необходимо.
  10. отлаживать
  11. Конец

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

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

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

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

s_ha_dum
источник
1
11. Конец - вам никогда не приходилось поддерживать / исправлять / улучшать сайт WordPress?
Саймон Ист
2

Посмотрите на стек скалы . Он использует composer для управления версией плагинов Wordpress и сторонних производителей, а также включает capistrano для развертываний и vagrant / ansible для настройки серверов, включая локальные виртуальные серверы для разработки.

rjmunro
источник
2

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

  • Я использую wp-cli для управления ядром WordPress и обновления WordPress.
  • Я использую composer вместе с http://wpackagist.org для управления зависимостями плагинов и тем.
  • Я использую git и помещаю основные файлы wp в .gitignore. Так что в основном файлы wp-config.php и дочерние темы находятся в git.

Я не знаком с инструментами миграции БД, но был бы отличным дополнением к этому рабочему процессу.

Вот полная информация о рабочем процессе http://geekpad.ca/blog/post/maintainble-portable-wordpress-using-composer-wp-cli

Патрик Забудь
источник
1

Что касается «клонирования» базы данных, я использую WP Migrate DB Pro: http://deliciousbrains.com/wp-migrate-db-pro/

Это платная услуга, но она не требует больших затрат и позволяет легко извлекать или перемещать вашу базу данных с вашего разработчика на живой сервер и наоборот. Он меняет URL-адреса и все остальное, что нужно изменить по пути.

deadlyhifi
источник
1
Знаете ли вы, учитывает ли сценарий db url replace, который он выполняет, сериализованные строки? Простой запрос на обновление для замены URL плох, потому что он разбивает любую сериализованную строку с URL-адресом в ней (если только новый URL-адрес не совпадает с количеством символов, что и старый URL-адрес, что по меньшей мере редко). Это разбивает текстовые виджеты и многие плагины среди прочего. Я использую этот скрипт прямо сейчас, но я бы заинтересовался этим плагином, если он делает то же самое.
Ennui
Я только что написал разработчику, чтобы он пришел и ответил на этот вопрос. У меня не было необходимости в этом (пока).
deadlyhifi
1
Я использую этот плагин для всех своих потребностей миграции и еще не видел каких-либо проблем с сериализованными строками и заменой URL. Все пользовательские поля переносятся без проблем. Имейте в виду, он заменяет ВСЕ по умолчанию. Это включает в себя пользователей / пароли / и т.д ...
hereswhatidid