Довідка робочого процесу Wordpress Git

Я шукаю сильну обтічну ідею робочого процесу для роботи з Wordpress.

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

Операція, ймовірно, піде приблизно так:

1. отримуючи останню останню версію wordpress та розгалужуючи її, ім'я гілки отримує запис піддомену (branchdevelopment.domain.com)
2. підмодуль тему, яку ви хочете, якщо вона доступна (я хотів би зробити для цього свою власну git repo, оскільки я використовую тезу, я хотів би мати пусту установку дисертації git repo, щоб захопити внутрішньо на вже створеному сервері)
3. оформити замовлення та внести зміни, відгуки клієнтів, після того, як його буде натиснути наживо, сценарій бази даних автоматично розпочне зміну серіалізованих значень URL з localhost (або субдомену) на прямий URL

Чи можливо це? Я чув, що Capistrano також добре використовувати з цим, але не впевнений, як Capistrano повністю працює.

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

Хтось має рішення щодо такого типу робочого процесу / працював з цим у минулому? Якщо так, деякі ресурси / відповідь будуть дуже вдячні.

Відповіли на загальні запитання

Nr.1 Хочеться, щоб моє середовище git було внутрішньо на моєму сервері, не використовуючи Github для обробки репостів.

Перше, що я хотів би зробити, це перевірити композитора та як він працює з WordPress , це проект Андрія "@Rarst" Савченко .

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

Це щось поза межами цього веб-сайту. Або зверніться за допомогою до StackOverflow або попросіть у вашого хостера. Деякі хостери не дозволяють самостійно редагувати ці записи.

Nr.3 Phing скрипт PHP / оболонки Обробка міграції db (щось подібне 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якщо вам потрібно переключити гілки.

№2. підмодуль тему, яку ви хочете, якщо вона доступна (я хотів би зробити для цього свою власну git repo, оскільки я використовую тезу, я хотів би мати пусту установку дипломної роботи git repo, щоб захопити внутрішньо на вже створеному сервері)

Томас "@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' );

Тепер просто покладіть всі ваші плагіни та теми під контроль версій та натисніть їх на свій сервер. Ви можете легко зробити їх усіма доступними за допомогою му-плагінів або плагінів за замовчуванням, які активують мережу.

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

Якщо скрипт / плагін Toms поки що не допомагає вам, то повідомляйте, що він приймає запит на виклик на GitHub .

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

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

• Потім я використовую це як через об'єднання піддірень у власних репо-сайтах (я навіть перебігаю помилку в git, але це рішення є тут: -X subtree = ... ).

Це означає, що ви можете мати налаштування WP, заснованого на магістралі / версії, який ви можете повністю зламати в т.ч. теми та плагіни.

Оскільки це одне незалежне (локальне) сховище, ви можете пересилати це через ssh до інших сховищ, наприклад одного:

• Він розташований на віддаленому хості, де сайт має бути розміщений (голе репо).
• Це має гачки, щоб зробити ще один сховище на цьому хості, фактично злившись із змінами, які ви щойно натиснули.

Про це йдеться у веб-зосередженому робочому процесі Git (листопад 2008; Джо Маллер) .

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

Вихідні зміни в WP ви просто отримуєте і об'єднуєте в піддерево.

Плагіни, які ви просто оновлюєте та здійснюєте.

Розгортання просте $ git push remote.

Запускайте щоденні резервні копії на віддаленому хості для git repos, бази даних та завантажених файлів, і це дешево, зручно для розробників та гнучко. Це добре працює як для налаштувань для одного розробника, так і для невеликих команд, тому що кожен може відмовитись від чистого репро на пульті.

Є кілька застережень:

• Псевдоніми 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 script Поводження з міграцією db (щось подібне http://interconnectit.com/products/search-and-replace-for-wordpress-databases/ ) для обробки серіалізованої заміни бази даних після натискання

Тут це не потрібно, оскільки лише код знаходиться під контролем версій, бази даних незалежні між розробкою (, постановкою) та виробництвом, як це має бути.

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

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

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

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

І якщо я щось навчився автоматизувати завдання: Дотримуйтесь філософії Unix, використовуйте існуючі та добре працюючі інструменти (краще витратити півдня на читання деяких команд, а потім на пошук альтернативних варіантів, оскільки для більшості робочих завдань проблеми були вирішено вже) і зосередитись на інструментах командного рядка. Вони найпотужніші.