WordPress Git Workflow Справка

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

1. Хотелось бы, чтобы моя среда git находилась на моем собственном сервере, не используя Github для работы с репозиториями.
2. Автоматическое создание поддоменов при создании ветки git (development.domain.com, ryan.development.domain.com) - Возможно, для этого подойдет некоторый хук сценария оболочки.
3. PHP / Shell скрипт Phing Обработка переноса БД (что-то вроде этого 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, чтобы я мог значительно упростить свою работу. На данный момент я в основном загружаю изображение сайта и работаю над ним локально, а затем загружаю изменения обратно на сервер. Это очень утомительно в наше время.

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

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

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

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

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

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

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

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

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

Операция Ответы на вопросы

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

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

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

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

Thomas "@toscho" Scholz написал хороший плагин, который позволяет нам использовать поддомен для обработки тем вне каталога 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-плагины или плагины по умолчанию, которые активируют сеть.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Есть несколько предостережений:

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

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

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

Здесь Github работает только с репозиториями верхнего уровня (Wordpress), а не с вашим собственным.

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

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

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