Справка по рабочему процессу Wordpress Git

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

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

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

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

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

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

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

Author: Ryan Dennler, 2013-09-03
Source

2 answers

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

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

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

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

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

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

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

WP Gear - проект Роберта "@Вика" Эллисона - содержит список альтернативных сценариев сборки. Включая Написание слов , написанное им самим. @тОмдЖНоуэллс/Interconnect.it сценария пока нет в этом списке.

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

Номер 1. получая текущую последнюю версию wordpress и разветвляя ее, название ветки получает запись поддомена (branchdevelopment.domain.com)

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

Короче говоря: Просто checkout 3.6-branch, если вам нужно переключить ветви.

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

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

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

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

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

 6
Author: kaiser, 2017-04-13 12:37:34

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

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

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

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

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

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

Это описано в Веб-ориентированном рабочем процессе Git (ноябрь 2008; Джо Маллер).

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

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

Плагины, которые вы просто обновляете и фиксируете.

Развертывание является простым $ git push remote.

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

Есть некоторые предостережения:

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

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

Github обрабатывает здесь только репозитории вверх по течению (Wordpress), а не ваши собственные один.

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

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

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

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

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

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

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

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

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

 3
Author: hakre, 2017-05-23 12:40:07