Помощь WordPress Git Workflow

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

  1. Хотелось бы иметь мою среду git на моем собственном сервере внутри, не используя Github для обработки репозиториев.
  2. Автоматическое создание субдоменов при создании ветвей git (development.domain.com, ryan.development.domain.com). Вероятно, для этого был бы идеальным крючком скриптового скрипта.
  3. Phing PHP / Shell. Обработка миграции db (что-то вроде этого http://interconnectit.com/products/search-and-replace-for-wordpress-databases/ ) для обработки сериализованной замены базы данных при нажатии

Операция, вероятно, будет выглядеть примерно так:

  1. получение текущей последней версии WordPress и разветвление ее, название ветки получает запись поддомена (branchdevelopment.domain.com)
  2. subodule тему, которую вы хотите, если она доступна (я хотел бы сделать свой собственный git-репо для этого, так как я использую тезис, я бы хотел, чтобы у вас была чистая репозитория git-репозитория, чтобы захватить внутренне на сервере, который уже был создан)
  3. проверка и внесение изменений, отзывы клиентов, после того, как она будет переведена на живую, скрипт базы данных затем автоматически переключит значения сериализованного URL-адреса с localhost (или поддомена) на живой URL-адрес

Это возможно? Я слышал, что Капистрано тоже хорош в использовании, но не уверен, как Капистрано полностью работает.

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

Есть ли у кого-нибудь какие-либо решения в отношении этого типа рабочего процесса / работал с этим в прошлом? Если это так, некоторые ресурсы / ответ будут очень признательны.

Solutions Collecting From Web of "Помощь WordPress Git Workflow"

Ответы на общие вопросы

Nr.1. Хотелось бы иметь мою среду git на моем собственном сервере внутри, не используя Github для обработки репозиториев.

Первое, что я хотел бы сделать, это проверить композитора и как он работает с WordPress , который является проектом Андрея «@Rarst» Савченко .

Nr.2. Автоматическое создание субдоменов при создании ветвей git ( development.example.com , ryan.development.example.com ). Вероятно, для этого был бы идеальным крючком скриптового скрипта.

Это не подходит для этого сайта. Или попросите о помощи в StackOverflow или спросите у хостера. Некоторые хостеры не позволяют редактировать эти записи самостоятельно.

Nr.3. Phing PHP / Shell. Обработка миграции db (что-то вроде этого http://interconnectit.com/products/search-and-replace-for-wordpress-databases/ ) для обработки сериализованной замены базы данных при нажатии

Я бы установил многопользовательскую / сетевую установку. Это позволяет легко управлять всеми таблицами, поддерживать пользователей в центральном месте и т. Д.

WP Gear – проект Роберта «@Wyck» Ellison – содержит список альтернативных скриптов сборки. В том числе WordPhing, написанный им самим. Сценарий @TomJNowells /Interconnect.it пока отсутствует в этом списке.

Ответы на вопросы

Nr. 1. получение текущей последней версии WordPress и разветвление ее, название ветки получает запись поддомена (branchdevelopment.domain.com)

Не уверен, зачем это нужно: субдомен для каждой ветки. Когда вы смотрите на синхронизированный репозиторий WordPress GitHub и список ветвей , вы увидите, что каждая ветвь называется XY-branch . Таким образом, ваши поддомены получили бы имя, например, 3.6-branch . Я не уверен, разрешено ли субдомену начинать с цифры (это должно быть, но спросите у хостера), а затем возникает проблема, заключающаяся в том, что вы получите суб-поддомен с именем 6-branch , у которого есть под-суб -поддомен по имени 3 а другой – по имени 2 . И угадать, что спаривание двух и трех версий ветвей в субдомене – это не то, чего вы хотите достичь.

Вкратце: просто checkout 3.6-branch если вам нужно переключить ветви.

Nr.2. subodule тему, которую вы хотите, если она доступна (я хотел бы сделать свой собственный git-репо для этого, так как я использую тезис, я бы хотел, чтобы у вас была чистая репозитория git-репозитория, чтобы захватить внутренне на сервере, который уже был создан)

Thomas «@toscho» Scholz написал хороший плагин, который позволяет нам использовать субдомен для обработки тем за пределами каталога WordPress. Вы можете найти его в этом ответе, а также в этом . Даже автоматические обновления будут работать для тем, начиная с WP 3.6.

Вы можете сделать то же самое для MU-Plugins и плагинов, просто установив следующие константы в файле wp-config.php :

 define( 'WP_PLUGIN_DIR', 'path/to/your/plugins.dev/folder/plugins' ); define( 'WP_PLUGIN_URL', 'https://plugins.dev/plugins' ); define( 'WPMU_PLUGIN_DIR', 'path/to/your/plugins.dev/folder/mu-plugins' ); define( 'WPMU_PLUGIN_URL', 'https://plugins.dev/mu-plugins' ); 

Теперь просто поместите все свои плагины и темы под контроль версий и нажмите их на свой сервер. Вы можете легко сделать их доступными с помощью mu-plugins или плагинов по умолчанию, которые активируют сеть.

Nr.3 и внести изменения, отзывы клиентов, после того, как он будет перенесен на жизнь, скрипт базы данных затем автоматически начнет изменять сериализованные значения url из localhost (или поддомена) в живой URL-адрес

Если скрипт / плагин Toms вам пока что не поможет, скажите, что он принимает запрос на загрузку GitHub .

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

  • Я клонирую WordPress из Github (вы можете даже сделать это для исходного дерева отсюда: tierra / wordpress )

  • Затем я использую его как через слияние поддерева на своих собственных сайтах repo (я даже запускаю ошибку в git, но это решение находится здесь: -X subtree = … ).

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

Поскольку это один независимый (локальный) репозиторий, вы можете нажать его через ssh в другие репозитории, например, один:

  • Это расположено на удаленном хосте, где сайт должен быть развернут (голый репо).
  • У этого есть крючки, чтобы сделать другой репозиторий на этом хосте фактически слиянием в изменениях, которые вы только что нажали.

Это описано в веб-ориентированном рабочем потоке Git (ноябрь 2008 г., Joe Maller) .

Если у вас есть переключатель конфигурации, который выбирает конкретный wp-config.php на основе системы, на которой он запущен, вы можете даже централизованно настроить все хосты (развитие, жить, постановка, друзья, …) внутри репо.

Изменения в восходящем потоке в WP вы просто извлекаете и объединяете в поддереве.

Плагины, которые вы только что обновили и зафиксировали.

Развертывание – простой $ git push remote .

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


Есть некоторые оговорки:

  • Git aliases git accept-theirs и git accept-theirs полезны в случае возникновения противоречивых базовых изменений, которые вы четко знаете, с кем вы предпочитаете иметь дело. Вы находите это здесь: Простой инструмент, чтобы «принять их» или «принять мой» на весь файл, используя git
  • Привет, Долли. Проклятие целого поколения. Вам нужно всегда это делать.

Теперь с вашим контрольным списком и настройкой, как описано выше:

1. Хотелось бы иметь мою среду git на моем собственном сервере внутри, не используя Github для обработки репозиториев.

Github только обрабатывает upstream repos здесь (WordPress), а не ваш собственный.

2. Автоматическое создание субдоменов при создании ветки git (development.domain.com, ryan.development.domain.com). Вероятно, для этого был бы идеальным крючком скриптового скрипта.

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

3. PHP-скрипт PHP / Shell. Обработка миграции db (что-то вроде этого http://interconnectit.com/products/search-and-replace-for-wordpress-databases/ ) для обработки серийной замены базы данных при нажатии

Здесь это не требуется, поскольку только код находится под контролем версий, базы данных независимы между разработкой (, постановкой) и производством, как и должно быть.

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

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

Я не могу себе представить, как эти сайты станут подчиняться среде рабочего потока git. Возможно, скрипты конфигурации и данные конфигурации, которыми вы управляете здесь, будут храниться под контролем версии git. Это может иметь смысл. В противном случае из-за огромного количества сайтов, я думаю, что нет никакого смысла держать всех в одном git-репо. Возможно, даже не один из них, потому что то, что я изложил выше, касается сайтов, которые вы разрабатываете (включая основной код WP), а не только для задач установки. Таким образом, вам, вероятно, нужно прежде всего создать себе небольшую карту этих 200 сайтов и как они взаимодействуют друг с другом и из которых состоят из этих пакетов (WP core, Plugins, Themes). Первое, что можно было бы создать таблицу / матрицу и разместить все сайты.

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

И если я чему-то научился с автоматизацией задач: следуйте философии Unix, используйте существующие и хорошо работающие инструменты (лучше потратить полдня на чтение некоторых команд, а затем попытаться найти альтернативы, потому что для большинства заданий проблемы были уже решены) и сосредоточиться на инструментах командной строки. Они самые могущественные.