WordPress та Git Workflow

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

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

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

- Керування розгортанням теми WordPress за допомогою Git

- Керуйте власною темою WordPress, використовуючи git замість FTP

Наразі мій робочий процес виглядає приблизно так.

• Встановіть WordPress локально
• Розробіть тему
• Експорт баз даних WordPress з локального сервера
• Імпорт бази даних WordPress на віддалений сервер
• Завантажте файли та теми WordPress через FTP
• Клієнт вносить зміни
• Завантажте файли та теми WordPress через FTP та експортуйте бази даних WordPress з віддаленого сервера
• Замініть файли локально
• Внесіть зміни в розвитку
• Повторне завантаження через FTP, експорт та імпорт бази даних на віддалений сервер

Я розумію, що Git може впорядкувати цей процес. Найкращим способом для цього є створення файлу .gitignore, який ігнорує певні каталоги, які не потрібно відстежувати, а також локальний та віддалений файл wp-config.php.

Але як ви обробляєте бази даних? Зазвичай клієнти вносять зміни (повідомлення / сторінки / плагіни). Чи потрібно мені експортувати з віддаленої бази даних та імпортувати назад на свій локальний сервер?

Чи може хтось запропонувати тут найкращий робочий процес для мене? І пройди мене по сходах.

Крім того, я, мабуть, хотів би використовувати Bitbucket, оскільки приватні репозиції з ними безкоштовні, на відміну від GitHub.

Будь-яка допомога буде вдячна.

Спасибі заздалегідь!

Я один із розробників WP Migrate DB Pro , і хотів би відповісти на запитання @ Ennui:

"Чи знаєте ви, що сценарій заміни db url, який він запускає, враховує серіалізовані рядки?"

Так, він обробляє серіалізовані дані. Насправді, це головна причина, що я розробив безкоштовну версію плагіна ще в 2009 році. :)

На жаль, у мене лише 41 репутація, тому я не зміг відповісти на коментар @ Ennui. Вибачте за це.

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

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

1. Встановіть WordPress локально
   1. Це клонується з місцевого голого Git repo, що містить останню стабільну версію.
   2. Я також зберігаю локальну копію останнього випуску кількох плагінів, які я майже завжди встановлюю.
2. Побудуйте тему та будь-які необхідні плагіни
3. Завантажити на загальнодоступний сервер налаштування
   1. Клієнту надається доступ, але він не може змінити код, і він сказав, що правки бази даних не будуть передані на виробничий сайт.
   2. Це означає, що немає ніяких підстав для завантаження коду назад на сервер розробки.
   3. І немає причин повторно синхронізувати локальну базу даних
4. Внесіть зміни на місцевий сайт на основі відгуків наших співробітників та клієнтів.
5. Завантажте зміни
6. Повторіть по мірі необхідності (але зі збільшенням опору :))
7. Якщо ми надаємо контент, що не завжди так, ми (не клієнт) будемо очищати базу даних на етапі сервера та завантажувати вміст.
8. Розгорнути, завантаживши локальний код на виробничий сайт.
9. Якщо ми створили контент, його вміст експортується з сайту постановки за допомогою інструменту експорту ванілі та імпортується на сайт виробництва.
   1. Це єдиний раз, коли мені доведеться переміщувати базу даних, і це робиться за допомогою досить стандартних інструментів. Я буду використовувати URL-адреси Velvet Blues Update для очищення бази даних, якщо потрібно.
10. Відлагоджувати
11. Кінець

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

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

І база даних переміщується лише один раз, якщо взагалі, що значно зменшує проблему. Тому я думаю, що я керую проблемою "переміщення бази даних", зменшуючи або усуваючи необхідність переміщення бази даних. Це також зменшує проблеми з корупцією бази даних, які можуть виникнути, і зменшує шанси на імпорт зламаного пристрою.

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

https://github.com/nathanielks/Wordpress-Capistrano-Deploy

Я сам ще цього не пробував (але), але він стверджує, що все розгорнути - включаючи БД.

Існує також підручник, який слід пройти з ним: Підручник, частина 1 | частина 2

Подивіться на стек скельному . Він використовує композитор для управління версією Wordpress та сторонніх плагінів, а також включає capistrano для розгортань та бродячий / відповідальний для налаштування серверів, включаючи локальні віртуальні сервери для розробки.

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

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

Я не знайомий з інструментами міграції db, але став би чудовим доповненням до цього робочого процесу.

Ось повна інформація про робочий процес http://geekpad.ca/blog/post/maintainble-portable-wordpress-using-composer-wp-cli

Щодо бази даних "клонування", я використовую WP Migrate DB Pro: http://deliciousbrains.com/wp-migrate-db-pro/

Це платна послуга, але не коштує багато коштів, і легко дозволяє вам перетягнути або відсунути базу даних з вашого розробника на ваш живий сервер і навпаки. Він змінює URL-адреси та все інше, що потребує змін у дорозі.