Процесс разработки Wordpress

Я хочу создать процесс разработки WordPress, как в следующем рисунке:

Сначала я хочу создать репозиторий bitbucket для моего сайта Wordpress. Из этого хранилища все наши разработчики программного обеспечения должны иметь возможность клонировать сайт на своих локальных машинах для разработки. Для разработки все разработчики должны иметь одну локальную базу данных для тестирования изменений.

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

Когда все тесты будут успешно выполнены, я хочу иметь возможность применить изменения базы данных к системе prod (с помощью SQL-скрипта) и отправить все изменения с другим конвейером/работой Jekins в систему prod.

Считаете ли вы, что это может сработать? Что происходит с обновлениями плагинов? Могу ли я настраивать переменные среды для каждой системы, чтобы обновления плагинов могли быть сделаны только на dev-машине?

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

Есть ли кто-то, у кого есть экспертные знания с wordpress и такого рода процесс развития, и можете поделиться своим опытом со мной?

Или вы думаете, что этот процесс не работает с wordpress? Если это так, это будет очень плохо, потому что мне нужен такой процесс.

Большое спасибо!

Ответ 1

Я действительно не знаю Wordpress, но процесс, который вы описываете, определенно возможен (например, я реализовал аналогичные решения для Drupal и Adobe Experience Manager).

Тем не мение...

Это тяжело.

В проекте CMS переменная/новая функция может включать в себя: - изменение кода (PHP, CSS, JavaScript) - изменение структуры базы данных (например, новую таблицу) - изменение содержимого базы данных (например, исправление копии или по умолчанию/тест содержимое) - изменение конфигурации

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

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

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

Ответ 2

Правильный ответ: да, вы можете это сделать. Я знаю WordPress, бит-ведро, GIT, SVN, Linux, Ubuntu исключительно хорошо. Я создал систему, очень похожую на то, что вы описываете и используете ее ежедневно.

Проблема заключается в том, что CMS может стать сложной задачей. Это верно, но вам нужно использовать правильные инструменты для правильного обновления. Таким образом, WordPress ALREADY имеет встроенные в него версии и ревизии. Базы данных не обязательно должны быть задействованы

Прежде всего. База данных не нуждается в обновлении, если вы не обновляете плагины. Но для строгого развития не нужны никакие нажатия DB. Так что ваши разработчики проверяют файлы в и из бит-ведра. Когда ведущий разработчик одобрит изменения, он перенесет/нажал MASTER BRANCH в вашем REPO. Внутри бит-ведра есть инструмент под названием GIT HOOKS. Вы можете запускать php файл на сервере каждый раз, когда есть нажатие на производственную ветку. Что делает файл PHP, просто запускает команду linux GIT PULL, которая обновит весь код на сервере с помощью того, что в вашем ПРОИЗВОДСТВЕННОМ ФИЛИАЛЕ. GIT PULL также удалит любые файлы, если файлы были удалены и т.д. На сервере у вас будет "выданная" копия репозитория GIT и на linux учетные данные после того, как будет сохранен первый клон. Просто попробуйте запустить PHP-скрипт BASH-скрипта, который выполняет GIT PULL. Готово.

Независимо от того, сколько у вас разработчиков есть, всегда будет нужно множество глаз, которые анализируют изменения кода и объединяют их в производство. То есть именно здесь играет Ведущий разработчик.

FYI. Единственными каталогами в вашем экземпляре wordpress, которые должны быть в битбакете, является папка THEME DIRECTORY и каталог PLUGINS. Вам НЕ нужно синхронизировать всю установку WP, которая довольно большая.

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

Вам нужно будет синхронизировать 2 каталога ниже.

Папка плагинов находится в: wp-content/plugins/

Темы Папка - wp-content/themes/SELECTED_THEME

Любые дополнительные вопросы просто спрашивают, и я здесь.

Ответ 3

По моему опыту всегда лучше разрешить каждому разработчику иметь собственный филиал и настроить сервер Dev на выделенную ведущую ветвь для контроля качества. вы можете проверить некоторые документы о том, как установить это https://plixxer.com/docs/server-management/website-quality-control/

в основном вы хотите иметь живой сервер и dev-сервер. Живой сервер должен только вытащить из REPO, а Dev и кодеры могут вытащить или нажать из репо. Моя команда рассматривает сервер dev как станцию проверки качества. Если текущий код в реальном времени не соответствует нашим стандартам, весь разработчик возвращается к тому, что находится на главной ветке. Когда код в мастере преуспевает в наших стандартах, мы выходим из ведущей ветки на живой сервер. Каждый разработчик должен иметь свою собственную ветку для тестирования на своем локальном сервере. Дайте мне знать, если вам нужна помощь в настройке локальной среды с GIT.

Ответ 4

Вы захотите провести различие вокруг "build" и еще что-то вокруг "release". Рабочий процесс, который я понимаю, заключается в том, что разработчики называют свои локальные рабочие станции "dev" и вытаскивают запрос на работу в ветку разработки (возможно, вы уже прочитали Gitflow). Затем, используя ваш выбор автоматизации CI, вы получаете последний источник в область сборки и делаете это - создавайте его. Отъезд: Ansible. Если у вас есть BitBucket, может быть, вы также захотите организовать свой спринт с подобными Джире? Тогда у вас есть довольно безвкусная интеграция ваших целей спринта с фактическими ветвями, содержащими относительную работу/источник. Ansible может помочь вам автоматизировать сборку и выпуск до того момента, когда вы делаете ежедневные сборки, и запускать модульные тесты в ваших сборках в различных средах интеграции.

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

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

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